From maurizio.cimadamore at oracle.com Tue Jan 3 11:24:49 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 3 Jan 2017 11:24:49 +0000 Subject: RFR 8171132: Improve class reading of invalid or out-of-range ConstantValue attributes In-Reply-To: <0ef41448-abe4-9ff6-9e1c-02c7e79f40a7@oracle.com> References: <5851AC06.7020706@oracle.com> <80352327-89c9-330a-cd31-bb5182152360@oracle.com> <0ef41448-abe4-9ff6-9e1c-02c7e79f40a7@oracle.com> Message-ID: <3991898f-adc7-a40b-9ded-d993fff81ea7@oracle.com> Pushed - thanks Maurizio On 15/12/16 19:02, Maurizio Cimadamore wrote: > > Thanks - I will push this in the next few days > > Maurizio > > > On 15/12/16 18:11, Liam Miller-Cushon wrote: >> Done: http://cr.openjdk.java.net/~cushon/8171132/webrev.03/ >> >> >> On Thu, Dec 15, 2016 at 5:29 AM, Maurizio Cimadamore >> wrote: >> >> Looks good - the only minor issue is that the new resource keys >> should probably be excluded in the examples-not-yet.txt file >> (otherwise diags test will fail). We typically try and provide an >> example of all diagnostics generated by javac. IN case of errors >> that are hard to reproduce (and classfile errors related to bad >> classfiles definitively fall in this category), we typically just >> omit the diagnostic key from the test (albeit it will be nice one >> day to have an example for _all_ diagnostics). >> >> Maurizio >> >> >> On 15/12/16 01:16, Liam Miller-Cushon wrote: >>> On Wed, Dec 14, 2016 at 12:31 PM, Alex Buckley >>> wrote: >>> >>> I'm not sure which spec you're asking about ... the JLS, for >>> example, doesn't mention reading class files so it can't be >>> that. I mentioned "quality-of-implementation detail" to >>> highlight that javac can react to the ConstantValue >>> attribute for Lib.B (or Test.TWO I guess) how ever it >>> wishes. javac could convert the value on Monday, zero it on >>> Tuesday, and throw error every other day. >>> >>> >>> Thanks! I was asking about the JVMS, which I understand doesn't >>> require a class file to be rejected for this reason. I now >>> realize it doesn't disallow that. >>> >>> I updated the change to report an error on out-of-range values: >>> http://cr.openjdk.java.net/~cushon/8171132/webrev.02/ >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Jan 3 21:21:31 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 3 Jan 2017 16:21:31 -0500 Subject: RFR 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage Message-ID: Hello, The JavacMessager API allows a message to be generated for a source position defined by a combination of Element + AnnotationMirror + AnnotationValue. The AnnotationValue is currently ignored, and the position is defined using only the Element and AnnotationMirror. This fix causes the AnnotationValue to be considered when calculating the diagnostic position. The value must be a direct value of the given annotation, or an element in an array initializer. Values of nested annotation mirrors are not supported. For example, given `@A(x = {1}, y = @B(2))` positions will be calculated for the AnnotationMirror + AnnotationValue pairs @A + {1}, @A + 1, and @B + 2, but not for @A + 2. Bug: https://bugs.openjdk.java.net/browse/JDK-6388543 Webrev: http://cr.openjdk.java.net/~cushon/6388543/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Jan 3 21:32:12 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 3 Jan 2017 16:32:12 -0500 Subject: RFR 8172213: Remove unused and partially implemented JavacElements#getSourcePosition methods Message-ID: JavacSourcePosition's documentation says: "Implementation of model API SourcePosition based on javac internal state." That model API class does not exist, and the methods are never used in javac. They can be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8172213 Webrev: http://cr.openjdk.java.net/~cushon/8172213/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Jan 3 21:58:05 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 3 Jan 2017 16:58:05 -0500 Subject: RFR 8172214: typo in 'intersection types in cast are not supported' message Message-ID: This fixes a typo in compiler.err.intersection.types.in.cast.not.supported.in.source, which incorrectly refers to default methods instead of intersection types in cast. Bug: https://bugs.openjdk.java.net/browse/JDK-8172214 Webrev: http://cr.openjdk.java.net/~cushon/8172214/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Jan 3 22:07:31 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 3 Jan 2017 22:07:31 +0000 Subject: RFR 8172214: typo in 'intersection types in cast are not supported' message In-Reply-To: References: Message-ID: <0f01b872-0288-9c61-ad97-a7528ee6f9bf@oracle.com> Looks good thanks! Maurizio On 03/01/17 21:58, Liam Miller-Cushon wrote: > This fixes a typo in > compiler.err.intersection.types.in.cast.not.supported.in.source, which > incorrectly refers to default methods instead of intersection types in > cast. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172214 > Webrev: http://cr.openjdk.java.net/~cushon/8172214/webrev.00/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Jan 4 00:41:03 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 03 Jan 2017 16:41:03 -0800 Subject: RFR 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage In-Reply-To: References: Message-ID: <586C449F.7050400@oracle.com> While not a review, since the API was designed to support the more precise message reporting, it would be good to see that functionality present in javac. Thanks, -Joe On 1/3/2017 1:21 PM, Liam Miller-Cushon wrote: > Hello, > > The JavacMessager API allows a message to be generated for a source > position defined by a combination of Element + AnnotationMirror + > AnnotationValue. The AnnotationValue is currently ignored, and the > position is defined using only the Element and AnnotationMirror. > > This fix causes the AnnotationValue to be considered when calculating > the diagnostic position. The value must be a direct value of the given > annotation, or an element in an array initializer. Values of nested > annotation mirrors are not supported. > > For example, given `@A(x = {1}, y = @B(2))` positions will be > calculated for the AnnotationMirror + AnnotationValue pairs @A + {1}, > @A + 1, and @B + 2, but not for @A + 2. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6388543 > Webrev: http://cr.openjdk.java.net/~cushon/6388543/webrev.00/ > From jonathan.gibbons at oracle.com Wed Jan 4 02:00:51 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 03 Jan 2017 18:00:51 -0800 Subject: RFR 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage In-Reply-To: References: Message-ID: <586C5753.903@oracle.com> On 01/03/2017 01:21 PM, Liam Miller-Cushon wrote: > Hello, > > The JavacMessager API allows a message to be generated for a source > position defined by a combination of Element + AnnotationMirror + > AnnotationValue. The AnnotationValue is currently ignored, and the > position is defined using only the Element and AnnotationMirror. > > This fix causes the AnnotationValue to be considered when calculating > the diagnostic position. The value must be a direct value of the given > annotation, or an element in an array initializer. Values of nested > annotation mirrors are not supported. > > For example, given `@A(x = {1}, y = @B(2))` positions will be > calculated for the AnnotationMirror + AnnotationValue pairs @A + {1}, > @A + 1, and @B + 2, but not for @A + 2. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6388543 > Webrev: http://cr.openjdk.java.net/~cushon/6388543/webrev.00/ > I guess I am slightly surprised by the proposed solution, as regards the choice of what it means to find a match. I have always assumed that any implementation would iterate over the element values of the annotation, looking for a value that is .equals to the given value, for some appropriate definition of AnnotationValue.equals. It does not seem obvious to me that you should be searching within the individual element values for the match. I am also surprised that you might match for @B + 2; I would expect the annotation mirror to only match at the top level. For example, assuming a "first one wins" policy, I would have expected @B + 2 to match the second annotation in the pair of annotations `@A(x = {1}, y = @B(2)) @B(2)` So, before getting into the details of the proposed code, I think it would be worthwhile to determine what the semantics of this somewhat loosely-specified "hint" should actually be. -- Jon From cushon at google.com Wed Jan 4 06:28:41 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 4 Jan 2017 01:28:41 -0500 Subject: RFR 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage In-Reply-To: <586C5753.903@oracle.com> References: <586C5753.903@oracle.com> Message-ID: Thanks for the feedback, On Tue, Jan 3, 2017 at 9:00 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > I guess I am slightly surprised by the proposed solution, as regards the > choice of what it means to find a match. I have always assumed that any > implementation would iterate over the element values of the annotation, > looking for a value that is .equals to the given value, for some > appropriate definition of AnnotationValue.equals. It does not seem obvious > to me that you should be searching within the individual element values for > the match. I am also surprised that you might match for @B + 2; I would > expect the annotation mirror to only match at the top level. For example, > assuming a "first one wins" policy, I would have expected @B + 2 to match > the second annotation in the pair of annotations `@A(x = {1}, y = @B(2)) > @B(2)` I thought the proposed approach was consistent with the existing handling of AnnotationMirror. The overloads of matchAnnoToTree use reference equality to find a matching AnnotationMirror, which could be either a top-level or nested annotation on the element. So given `@A(x = {1}, y = @B(2)) @B(2)`, passing an AnnotationMirror for @B to printMessage(..., Element, AnnotationMirror) could match either appearance of @B depending on which instance the argument was. Is there a definition of AnnotationValue.equals that would be more appropriate than reference equality? Value equality would be ambiguous for e.g. `@A(x=1, y=1, z=1)` and @A + 1. The motivation for supporting array elements was the same one mentioned in the bug [1], which I've heard repeated elsewhere: for annotations containing large array initializers it'd be helpful to place the caret at a specific element instead of the start of the array. Liam [1] https://bugs.openjdk.java.net/browse/JDK-6388543?focusedCommentId=12267020&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12267020 -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Jan 4 15:35:39 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 4 Jan 2017 15:35:39 +0000 Subject: RFR 8172214: typo in 'intersection types in cast are not supported' message In-Reply-To: <0f01b872-0288-9c61-ad97-a7528ee6f9bf@oracle.com> References: <0f01b872-0288-9c61-ad97-a7528ee6f9bf@oracle.com> Message-ID: Pushed - thanks Maurizio On 03/01/17 22:07, Maurizio Cimadamore wrote: > > Looks good thanks! > > Maurizio > > > On 03/01/17 21:58, Liam Miller-Cushon wrote: >> This fixes a typo in >> compiler.err.intersection.types.in.cast.not.supported.in.source, >> which incorrectly refers to default methods instead of intersection >> types in cast. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172214 >> Webrev: http://cr.openjdk.java.net/~cushon/8172214/webrev.00/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Jan 5 16:35:50 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 5 Jan 2017 16:35:50 +0000 Subject: RFR: backport for fix https://bugs.openjdk.java.net/browse/JDK-8172291 Message-ID: <66bedc11-561f-3912-46ed-517ee42fe466@oracle.com> Hi, please review the backport: https://bugs.openjdk.java.net/browse/JDK-8172291 The original issue is here (fixed in 9): https://bugs.openjdk.java.net/browse/JDK-8168774 The JDK 9 patch does not apply cleanly because: * Types.isSignaturePolymorphic has changed in 9 because of VarHandles * the test (BadPolySig) contains jtreg module directives which are not valid in 8 Webrev here: http://cr.openjdk.java.net/~mcimadamore/8172291/ Cheers Maurizio From vicente.romero at oracle.com Thu Jan 5 17:47:29 2017 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 5 Jan 2017 12:47:29 -0500 Subject: RFR: backport for fix https://bugs.openjdk.java.net/browse/JDK-8172291 In-Reply-To: <66bedc11-561f-3912-46ed-517ee42fe466@oracle.com> References: <66bedc11-561f-3912-46ed-517ee42fe466@oracle.com> Message-ID: <4c9a8940-3860-b033-4a64-271f022dab12@oracle.com> accepted Vicente On 01/05/2017 11:35 AM, Maurizio Cimadamore wrote: > Hi, > please review the backport: > > https://bugs.openjdk.java.net/browse/JDK-8172291 > > The original issue is here (fixed in 9): > > https://bugs.openjdk.java.net/browse/JDK-8168774 > > The JDK 9 patch does not apply cleanly because: > > * Types.isSignaturePolymorphic has changed in 9 because of VarHandles > * the test (BadPolySig) contains jtreg module directives which are not > valid in 8 > > Webrev here: > > http://cr.openjdk.java.net/~mcimadamore/8172291/ > > Cheers > Maurizio > > From vicente.romero at oracle.com Thu Jan 5 19:32:35 2017 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 5 Jan 2017 14:32:35 -0500 Subject: [PATCH] 8148100: Convert lambda most specific positive tests to check runtime behavior In-Reply-To: References: <884c028b-f20e-53e2-5314-6ca2569556c6@oracle.com> Message-ID: pushed, Thanks, Vicente On 12/14/2016 09:50 AM, Vicente Romero wrote: > Hi Bernard, > > Very sorry for the delay with your patch, I will take care of it, > > Vicente > > On 12/12/2016 04:40 AM, B. Blaser wrote: >> Hi, >> Does this patch need to be improved? >> >> Thanks, >> Bernard >> >> 2016-09-21 16:24 GMT+02:00 bsrbnd : >>> Please find in attachment an all-in-one patch for the 9 tests, as >>> discussed previously. >>> >>> Bernard >>> >>> >>> 2016-09-19 16:01 GMT+02:00 bsrbnd : >>>> Thanks for your advices. >>>> >>>> I re-wrote, below, the patch in a more compliant way (I hope). >>>> I'll perhaps (probably) also go through the 8 others soon, if I >>>> have time... >>>> >>>> Bernard >>>> >>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java >>>> b/test/tools/javac/lambda/MostSpecific10.java >>>> --- a/test/tools/javac/lambda/MostSpecific10.java >>>> +++ b/test/tools/javac/lambda/MostSpecific10.java >>>> @@ -25,9 +25,12 @@ >>>> * @test >>>> * @bug 8034223 >>>> * @summary Structural most-specific logic for lambdas, method refs, >>>> parens, and conditionals >>>> - * @compile MostSpecific10.java >>>> */ >>>> -class MostSpecific10 { >>>> +public class MostSpecific10 { >>>> + >>>> + public static void main(String[] args) { >>>> + new MostSpecific10().test(true); >>>> + } >>>> >>>> interface GetInt { >>>> int get(); >>>> @@ -38,7 +41,9 @@ >>>> } >>>> >>>> void m(GetInt getter) {} >>>> - void m(GetInteger getter) {} >>>> + void m(GetInteger getter) { >>>> + throw new RuntimeException("Less-specific method invocation: >>>> " + getter.getClass()); >>>> + } >>>> >>>> void test(boolean cond) { >>>> m(() -> 23); >>>> >>>> >>>> 2016-09-18 3:11 GMT+02:00 Jonathan Gibbons >>>> : >>>>> Bernard, >>>>> >>>>> Thanks for posting this patch. >>>>> >>>>> It's not wrong to say it explicitly, but the addition of the "@run >>>>> main" >>>>> line is unnecessary, since that is the default behavior once you >>>>> remove the >>>>> @compile. >>>>> >>>>> The replacement for void m(GetInteger getter) should be formatted >>>>> in a more >>>>> standard manner. >>>>> >>>>> It's more common to put the main method at the head of a test, >>>>> instead of at >>>>> the end. >>>>> >>>>> We can't check in "partial patches", so either you have to look at >>>>> the 8 >>>>> other tests and fix them all together, or we have to accept this >>>>> one change >>>>> as a "complete" fix for 8148100, and open a new, different issue >>>>> for the 8 >>>>> other tests. (The OpenJDK rules only permit one changeset per >>>>> issue per >>>>> repo,) >>>>> >>>>> -- Jon >>>>> >>>>> >>>>> >>>>> >>>>> On 9/17/16 10:16 AM, bsrbnd wrote: >>>>>> Hi, >>>>>> >>>>>> I just wrote a partial patch for issue 8148100. >>>>>> This is an updated version of >>>>>> test/tools/javac/lambda/MostSpecific10.java that verifies if the >>>>>> most-specific method is run with respect to JLS 15.12.2 (and also as >>>>>> explained in the issue description). >>>>>> I've not checked the 8 other tests yet... >>>>>> >>>>>> Regards, >>>>>> Bernard >>>>>> >>>>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java >>>>>> b/test/tools/javac/lambda/MostSpecific10.java >>>>>> --- a/test/tools/javac/lambda/MostSpecific10.java >>>>>> +++ b/test/tools/javac/lambda/MostSpecific10.java >>>>>> @@ -26,8 +26,9 @@ >>>>>> * @bug 8034223 >>>>>> * @summary Structural most-specific logic for lambdas, method >>>>>> refs, >>>>>> parens, and conditionals >>>>>> * @compile MostSpecific10.java >>>>>> + * @run main MostSpecific10 >>>>>> */ >>>>>> -class MostSpecific10 { >>>>>> +public class MostSpecific10 { >>>>>> >>>>>> interface GetInt { >>>>>> int get(); >>>>>> @@ -38,7 +39,7 @@ >>>>>> } >>>>>> >>>>>> void m(GetInt getter) {} >>>>>> - void m(GetInteger getter) {} >>>>>> + void m(GetInteger getter) {throw new >>>>>> RuntimeException("Less-specific method invocation: " + >>>>>> getter.getClass());} >>>>>> >>>>>> void test(boolean cond) { >>>>>> m(() -> 23); >>>>>> @@ -50,5 +51,9 @@ >>>>>> m(cond ? (() -> 23) : ("abc"::length) ); >>>>>> m(( cond ? () -> 23 : cond ? ("abc"::length) : (() -> >>>>>> 23) )); >>>>>> } >>>>>> + >>>>>> + public static void main(String[] args) { >>>>>> + new MostSpecific10().test(true); >>>>>> + } >>>>>> >>>>>> } >>>>> > From bsrbnd at gmail.com Sun Jan 8 12:43:22 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 8 Jan 2017 13:43:22 +0100 Subject: [PATCH] 8148100: Convert lambda most specific positive tests to check runtime behavior In-Reply-To: References: <884c028b-f20e-53e2-5314-6ca2569556c6@oracle.com> Message-ID: Fine, thanks! Bernard 2017-01-05 20:32 GMT+01:00 Vicente Romero : > pushed, > > Thanks, > Vicente > > > On 12/14/2016 09:50 AM, Vicente Romero wrote: >> >> Hi Bernard, >> >> Very sorry for the delay with your patch, I will take care of it, >> >> Vicente >> >> On 12/12/2016 04:40 AM, B. Blaser wrote: >>> >>> Hi, >>> Does this patch need to be improved? >>> >>> Thanks, >>> Bernard >>> >>> 2016-09-21 16:24 GMT+02:00 bsrbnd : >>>> >>>> Please find in attachment an all-in-one patch for the 9 tests, as >>>> discussed previously. >>>> >>>> Bernard >>>> >>>> >>>> 2016-09-19 16:01 GMT+02:00 bsrbnd : >>>>> >>>>> Thanks for your advices. >>>>> >>>>> I re-wrote, below, the patch in a more compliant way (I hope). >>>>> I'll perhaps (probably) also go through the 8 others soon, if I have >>>>> time... >>>>> >>>>> Bernard >>>>> >>>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java >>>>> b/test/tools/javac/lambda/MostSpecific10.java >>>>> --- a/test/tools/javac/lambda/MostSpecific10.java >>>>> +++ b/test/tools/javac/lambda/MostSpecific10.java >>>>> @@ -25,9 +25,12 @@ >>>>> * @test >>>>> * @bug 8034223 >>>>> * @summary Structural most-specific logic for lambdas, method refs, >>>>> parens, and conditionals >>>>> - * @compile MostSpecific10.java >>>>> */ >>>>> -class MostSpecific10 { >>>>> +public class MostSpecific10 { >>>>> + >>>>> + public static void main(String[] args) { >>>>> + new MostSpecific10().test(true); >>>>> + } >>>>> >>>>> interface GetInt { >>>>> int get(); >>>>> @@ -38,7 +41,9 @@ >>>>> } >>>>> >>>>> void m(GetInt getter) {} >>>>> - void m(GetInteger getter) {} >>>>> + void m(GetInteger getter) { >>>>> + throw new RuntimeException("Less-specific method invocation: >>>>> " + getter.getClass()); >>>>> + } >>>>> >>>>> void test(boolean cond) { >>>>> m(() -> 23); >>>>> >>>>> >>>>> 2016-09-18 3:11 GMT+02:00 Jonathan Gibbons >>>>> : >>>>>> >>>>>> Bernard, >>>>>> >>>>>> Thanks for posting this patch. >>>>>> >>>>>> It's not wrong to say it explicitly, but the addition of the "@run >>>>>> main" >>>>>> line is unnecessary, since that is the default behavior once you >>>>>> remove the >>>>>> @compile. >>>>>> >>>>>> The replacement for void m(GetInteger getter) should be formatted in a >>>>>> more >>>>>> standard manner. >>>>>> >>>>>> It's more common to put the main method at the head of a test, instead >>>>>> of at >>>>>> the end. >>>>>> >>>>>> We can't check in "partial patches", so either you have to look at the >>>>>> 8 >>>>>> other tests and fix them all together, or we have to accept this one >>>>>> change >>>>>> as a "complete" fix for 8148100, and open a new, different issue for >>>>>> the 8 >>>>>> other tests. (The OpenJDK rules only permit one changeset per issue >>>>>> per >>>>>> repo,) >>>>>> >>>>>> -- Jon >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 9/17/16 10:16 AM, bsrbnd wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I just wrote a partial patch for issue 8148100. >>>>>>> This is an updated version of >>>>>>> test/tools/javac/lambda/MostSpecific10.java that verifies if the >>>>>>> most-specific method is run with respect to JLS 15.12.2 (and also as >>>>>>> explained in the issue description). >>>>>>> I've not checked the 8 other tests yet... >>>>>>> >>>>>>> Regards, >>>>>>> Bernard >>>>>>> >>>>>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java >>>>>>> b/test/tools/javac/lambda/MostSpecific10.java >>>>>>> --- a/test/tools/javac/lambda/MostSpecific10.java >>>>>>> +++ b/test/tools/javac/lambda/MostSpecific10.java >>>>>>> @@ -26,8 +26,9 @@ >>>>>>> * @bug 8034223 >>>>>>> * @summary Structural most-specific logic for lambdas, method >>>>>>> refs, >>>>>>> parens, and conditionals >>>>>>> * @compile MostSpecific10.java >>>>>>> + * @run main MostSpecific10 >>>>>>> */ >>>>>>> -class MostSpecific10 { >>>>>>> +public class MostSpecific10 { >>>>>>> >>>>>>> interface GetInt { >>>>>>> int get(); >>>>>>> @@ -38,7 +39,7 @@ >>>>>>> } >>>>>>> >>>>>>> void m(GetInt getter) {} >>>>>>> - void m(GetInteger getter) {} >>>>>>> + void m(GetInteger getter) {throw new >>>>>>> RuntimeException("Less-specific method invocation: " + >>>>>>> getter.getClass());} >>>>>>> >>>>>>> void test(boolean cond) { >>>>>>> m(() -> 23); >>>>>>> @@ -50,5 +51,9 @@ >>>>>>> m(cond ? (() -> 23) : ("abc"::length) ); >>>>>>> m(( cond ? () -> 23 : cond ? ("abc"::length) : (() -> 23) >>>>>>> )); >>>>>>> } >>>>>>> + >>>>>>> + public static void main(String[] args) { >>>>>>> + new MostSpecific10().test(true); >>>>>>> + } >>>>>>> >>>>>>> } >>>>>> >>>>>> >> > From joe.darcy at oracle.com Tue Jan 10 00:02:13 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 9 Jan 2017 16:02:13 -0800 Subject: JDK 9 RFR of JDK-8172458: Make javax.lang.model javadoc HTML 5 compliant Message-ID: <8789276c-8cad-8d31-6435-02555cd470ba@oracle.com> Hello, The javadoc in javax.lang.model.* and javax.annotation.processing use some constructs that are not HTML 5 compliant. These constructs should be updated to be compliant with HTML 5, mostly replacing tags with . Please review the proposed changes below: JDK-8172458: Make javax.lang.model javadoc HTML 5 compliant: https://bugs.openjdk.java.net/browse/JDK-8172458 webrev: http://cr.openjdk.java.net/~darcy/8172458.0/ Thanks, -Joe From jonathan.gibbons at oracle.com Tue Jan 10 00:18:04 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 09 Jan 2017 16:18:04 -0800 Subject: JDK 9 RFR of JDK-8172458: Make javax.lang.model javadoc HTML 5 compliant In-Reply-To: <8789276c-8cad-8d31-6435-02555cd470ba@oracle.com> References: <8789276c-8cad-8d31-6435-02555cd470ba@oracle.com> Message-ID: <5874283C.7080604@oracle.com> Looks good to me. -- Jon On 01/09/2017 04:02 PM, joe darcy wrote: > Hello, > > The javadoc in javax.lang.model.* and javax.annotation.processing use > some constructs that are not HTML 5 compliant. These constructs should > be updated to be compliant with HTML 5, mostly replacing > tags with . Please review the proposed changes below: > > JDK-8172458: Make javax.lang.model javadoc HTML 5 compliant: > https://bugs.openjdk.java.net/browse/JDK-8172458 > webrev: http://cr.openjdk.java.net/~darcy/8172458.0/ > > Thanks, > > -Joe > > From asim2025 at yahoo.com Tue Jan 10 01:07:15 2017 From: asim2025 at yahoo.com (Asim Aslam) Date: Mon, 9 Jan 2017 20:07:15 -0500 Subject: compiler-dev Digest, Vol 117, Issue 3 In-Reply-To: References: Message-ID: <258176FC-F7AA-48ED-9EE3-804F1BF63B37@yahoo.com> > On Jan 9, 2017, at 7:02 PM, compiler-dev-request at openjdk.java.net wrote: > > Send compiler-dev mailing list submissions to > compiler-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/compiler-dev > or, via email, send a message with subject or body 'help' to > compiler-dev-request at openjdk.java.net > > You can reach the person managing the list at > compiler-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of compiler-dev digest..." > > > Today's Topics: > > 1. Re: RFR 8172214: typo in 'intersection types in cast are not > supported' message (Maurizio Cimadamore) > 2. RFR: backport for fix > https://bugs.openjdk.java.net/browse/JDK-8172291 (Maurizio Cimadamore) > 3. Re: RFR: backport for fix > https://bugs.openjdk.java.net/browse/JDK-8172291 (Vicente Romero) > 4. Re: [PATCH] 8148100: Convert lambda most specific positive > tests to check runtime behavior (Vicente Romero) > 5. Re: [PATCH] 8148100: Convert lambda most specific positive > tests to check runtime behavior (B. Blaser) > 6. JDK 9 RFR of JDK-8172458: Make javax.lang.model javadoc HTML > 5 compliant (joe darcy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 4 Jan 2017 15:35:39 +0000 > From: Maurizio Cimadamore > To: Liam Miller-Cushon , > "compiler-dev at openjdk.java.net" > Subject: Re: RFR 8172214: typo in 'intersection types in cast are not > supported' message > Message-ID: > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Pushed - thanks > > Maurizio > > >> On 03/01/17 22:07, Maurizio Cimadamore wrote: >> >> Looks good thanks! >> >> Maurizio >> >> >>> On 03/01/17 21:58, Liam Miller-Cushon wrote: >>> This fixes a typo in >>> compiler.err.intersection.types.in.cast.not.supported.in.source, >>> which incorrectly refers to default methods instead of intersection >>> types in cast. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172214 >>> Webrev: http://cr.openjdk.java.net/~cushon/8172214/webrev.00/ >>> >> > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Thu, 5 Jan 2017 16:35:50 +0000 > From: Maurizio Cimadamore > To: "compiler-dev at openjdk.java.net" > Subject: RFR: backport for fix > https://bugs.openjdk.java.net/browse/JDK-8172291 > Message-ID: <66bedc11-561f-3912-46ed-517ee42fe466 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi, > please review the backport: > > https://bugs.openjdk.java.net/browse/JDK-8172291 > > The original issue is here (fixed in 9): > > https://bugs.openjdk.java.net/browse/JDK-8168774 > > The JDK 9 patch does not apply cleanly because: > > * Types.isSignaturePolymorphic has changed in 9 because of VarHandles > * the test (BadPolySig) contains jtreg module directives which are not > valid in 8 > > Webrev here: > > http://cr.openjdk.java.net/~mcimadamore/8172291/ > > Cheers > Maurizio > > > > > ------------------------------ > > Message: 3 > Date: Thu, 5 Jan 2017 12:47:29 -0500 > From: Vicente Romero > To: Maurizio Cimadamore , > "compiler-dev at openjdk.java.net" > Subject: Re: RFR: backport for fix > https://bugs.openjdk.java.net/browse/JDK-8172291 > Message-ID: <4c9a8940-3860-b033-4a64-271f022dab12 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > accepted > > Vicente > > >> On 01/05/2017 11:35 AM, Maurizio Cimadamore wrote: >> Hi, >> please review the backport: >> >> https://bugs.openjdk.java.net/browse/JDK-8172291 >> >> The original issue is here (fixed in 9): >> >> https://bugs.openjdk.java.net/browse/JDK-8168774 >> >> The JDK 9 patch does not apply cleanly because: >> >> * Types.isSignaturePolymorphic has changed in 9 because of VarHandles >> * the test (BadPolySig) contains jtreg module directives which are not >> valid in 8 >> >> Webrev here: >> >> http://cr.openjdk.java.net/~mcimadamore/8172291/ >> >> Cheers >> Maurizio >> >> > > > > ------------------------------ > > Message: 4 > Date: Thu, 5 Jan 2017 14:32:35 -0500 > From: Vicente Romero > To: "B. Blaser" , Jonathan Gibbons > > Cc: compiler-dev at openjdk.java.net > Subject: Re: [PATCH] 8148100: Convert lambda most specific positive > tests to check runtime behavior > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > pushed, > > Thanks, > Vicente > >> On 12/14/2016 09:50 AM, Vicente Romero wrote: >> Hi Bernard, >> >> Very sorry for the delay with your patch, I will take care of it, >> >> Vicente >> >>> On 12/12/2016 04:40 AM, B. Blaser wrote: >>> Hi, >>> Does this patch need to be improved? >>> >>> Thanks, >>> Bernard >>> >>> 2016-09-21 16:24 GMT+02:00 bsrbnd : >>>> Please find in attachment an all-in-one patch for the 9 tests, as >>>> discussed previously. >>>> >>>> Bernard >>>> >>>> >>>> 2016-09-19 16:01 GMT+02:00 bsrbnd : >>>>> Thanks for your advices. >>>>> >>>>> I re-wrote, below, the patch in a more compliant way (I hope). >>>>> I'll perhaps (probably) also go through the 8 others soon, if I >>>>> have time... >>>>> >>>>> Bernard >>>>> >>>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java >>>>> b/test/tools/javac/lambda/MostSpecific10.java >>>>> --- a/test/tools/javac/lambda/MostSpecific10.java >>>>> +++ b/test/tools/javac/lambda/MostSpecific10.java >>>>> @@ -25,9 +25,12 @@ >>>>> * @test >>>>> * @bug 8034223 >>>>> * @summary Structural most-specific logic for lambdas, method refs, >>>>> parens, and conditionals >>>>> - * @compile MostSpecific10.java >>>>> */ >>>>> -class MostSpecific10 { >>>>> +public class MostSpecific10 { >>>>> + >>>>> + public static void main(String[] args) { >>>>> + new MostSpecific10().test(true); >>>>> + } >>>>> >>>>> interface GetInt { >>>>> int get(); >>>>> @@ -38,7 +41,9 @@ >>>>> } >>>>> >>>>> void m(GetInt getter) {} >>>>> - void m(GetInteger getter) {} >>>>> + void m(GetInteger getter) { >>>>> + throw new RuntimeException("Less-specific method invocation: >>>>> " + getter.getClass()); >>>>> + } >>>>> >>>>> void test(boolean cond) { >>>>> m(() -> 23); >>>>> >>>>> >>>>> 2016-09-18 3:11 GMT+02:00 Jonathan Gibbons >>>>> : >>>>>> Bernard, >>>>>> >>>>>> Thanks for posting this patch. >>>>>> >>>>>> It's not wrong to say it explicitly, but the addition of the "@run >>>>>> main" >>>>>> line is unnecessary, since that is the default behavior once you >>>>>> remove the >>>>>> @compile. >>>>>> >>>>>> The replacement for void m(GetInteger getter) should be formatted >>>>>> in a more >>>>>> standard manner. >>>>>> >>>>>> It's more common to put the main method at the head of a test, >>>>>> instead of at >>>>>> the end. >>>>>> >>>>>> We can't check in "partial patches", so either you have to look at >>>>>> the 8 >>>>>> other tests and fix them all together, or we have to accept this >>>>>> one change >>>>>> as a "complete" fix for 8148100, and open a new, different issue >>>>>> for the 8 >>>>>> other tests. (The OpenJDK rules only permit one changeset per >>>>>> issue per >>>>>> repo,) >>>>>> >>>>>> -- Jon >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On 9/17/16 10:16 AM, bsrbnd wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I just wrote a partial patch for issue 8148100. >>>>>>> This is an updated version of >>>>>>> test/tools/javac/lambda/MostSpecific10.java that verifies if the >>>>>>> most-specific method is run with respect to JLS 15.12.2 (and also as >>>>>>> explained in the issue description). >>>>>>> I've not checked the 8 other tests yet... >>>>>>> >>>>>>> Regards, >>>>>>> Bernard >>>>>>> >>>>>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java >>>>>>> b/test/tools/javac/lambda/MostSpecific10.java >>>>>>> --- a/test/tools/javac/lambda/MostSpecific10.java >>>>>>> +++ b/test/tools/javac/lambda/MostSpecific10.java >>>>>>> @@ -26,8 +26,9 @@ >>>>>>> * @bug 8034223 >>>>>>> * @summary Structural most-specific logic for lambdas, method >>>>>>> refs, >>>>>>> parens, and conditionals >>>>>>> * @compile MostSpecific10.java >>>>>>> + * @run main MostSpecific10 >>>>>>> */ >>>>>>> -class MostSpecific10 { >>>>>>> +public class MostSpecific10 { >>>>>>> >>>>>>> interface GetInt { >>>>>>> int get(); >>>>>>> @@ -38,7 +39,7 @@ >>>>>>> } >>>>>>> >>>>>>> void m(GetInt getter) {} >>>>>>> - void m(GetInteger getter) {} >>>>>>> + void m(GetInteger getter) {throw new >>>>>>> RuntimeException("Less-specific method invocation: " + >>>>>>> getter.getClass());} >>>>>>> >>>>>>> void test(boolean cond) { >>>>>>> m(() -> 23); >>>>>>> @@ -50,5 +51,9 @@ >>>>>>> m(cond ? (() -> 23) : ("abc"::length) ); >>>>>>> m(( cond ? () -> 23 : cond ? ("abc"::length) : (() -> >>>>>>> 23) )); >>>>>>> } >>>>>>> + >>>>>>> + public static void main(String[] args) { >>>>>>> + new MostSpecific10().test(true); >>>>>>> + } >>>>>>> >>>>>>> } >>>>>> >> > > > > ------------------------------ > > Message: 5 > Date: Sun, 8 Jan 2017 13:43:22 +0100 > From: "B. Blaser" > To: Vicente Romero > Cc: compiler-dev at openjdk.java.net > Subject: Re: [PATCH] 8148100: Convert lambda most specific positive > tests to check runtime behavior > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > Fine, thanks! > Bernard > > 2017-01-05 20:32 GMT+01:00 Vicente Romero : >> pushed, >> >> Thanks, >> Vicente >> >> >>> On 12/14/2016 09:50 AM, Vicente Romero wrote: >>> >>> Hi Bernard, >>> >>> Very sorry for the delay with your patch, I will take care of it, >>> >>> Vicente >>> >>>> On 12/12/2016 04:40 AM, B. Blaser wrote: >>>> >>>> Hi, >>>> Does this patch need to be improved? >>>> >>>> Thanks, >>>> Bernard >>>> >>>> 2016-09-21 16:24 GMT+02:00 bsrbnd : >>>>> >>>>> Please find in attachment an all-in-one patch for the 9 tests, as >>>>> discussed previously. >>>>> >>>>> Bernard >>>>> >>>>> >>>>> 2016-09-19 16:01 GMT+02:00 bsrbnd : >>>>>> >>>>>> Thanks for your advices. >>>>>> >>>>>> I re-wrote, below, the patch in a more compliant way (I hope). >>>>>> I'll perhaps (probably) also go through the 8 others soon, if I have >>>>>> time... >>>>>> >>>>>> Bernard >>>>>> >>>>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java >>>>>> b/test/tools/javac/lambda/MostSpecific10.java >>>>>> --- a/test/tools/javac/lambda/MostSpecific10.java >>>>>> +++ b/test/tools/javac/lambda/MostSpecific10.java >>>>>> @@ -25,9 +25,12 @@ >>>>>> * @test >>>>>> * @bug 8034223 >>>>>> * @summary Structural most-specific logic for lambdas, method refs, >>>>>> parens, and conditionals >>>>>> - * @compile MostSpecific10.java >>>>>> */ >>>>>> -class MostSpecific10 { >>>>>> +public class MostSpecific10 { >>>>>> + >>>>>> + public static void main(String[] args) { >>>>>> + new MostSpecific10().test(true); >>>>>> + } >>>>>> >>>>>> interface GetInt { >>>>>> int get(); >>>>>> @@ -38,7 +41,9 @@ >>>>>> } >>>>>> >>>>>> void m(GetInt getter) {} >>>>>> - void m(GetInteger getter) {} >>>>>> + void m(GetInteger getter) { >>>>>> + throw new RuntimeException("Less-specific method invocation: >>>>>> " + getter.getClass()); >>>>>> + } >>>>>> >>>>>> void test(boolean cond) { >>>>>> m(() -> 23); >>>>>> >>>>>> >>>>>> 2016-09-18 3:11 GMT+02:00 Jonathan Gibbons >>>>>> : >>>>>>> >>>>>>> Bernard, >>>>>>> >>>>>>> Thanks for posting this patch. >>>>>>> >>>>>>> It's not wrong to say it explicitly, but the addition of the "@run >>>>>>> main" >>>>>>> line is unnecessary, since that is the default behavior once you >>>>>>> remove the >>>>>>> @compile. >>>>>>> >>>>>>> The replacement for void m(GetInteger getter) should be formatted in a >>>>>>> more >>>>>>> standard manner. >>>>>>> >>>>>>> It's more common to put the main method at the head of a test, instead >>>>>>> of at >>>>>>> the end. >>>>>>> >>>>>>> We can't check in "partial patches", so either you have to look at the >>>>>>> 8 >>>>>>> other tests and fix them all together, or we have to accept this one >>>>>>> change >>>>>>> as a "complete" fix for 8148100, and open a new, different issue for >>>>>>> the 8 >>>>>>> other tests. (The OpenJDK rules only permit one changeset per issue >>>>>>> per >>>>>>> repo,) >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 9/17/16 10:16 AM, bsrbnd wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I just wrote a partial patch for issue 8148100. >>>>>>>> This is an updated version of >>>>>>>> test/tools/javac/lambda/MostSpecific10.java that verifies if the >>>>>>>> most-specific method is run with respect to JLS 15.12.2 (and also as >>>>>>>> explained in the issue description). >>>>>>>> I've not checked the 8 other tests yet... >>>>>>>> >>>>>>>> Regards, >>>>>>>> Bernard >>>>>>>> >>>>>>>> diff --git a/test/tools/javac/lambda/MostSpecific10.java >>>>>>>> b/test/tools/javac/lambda/MostSpecific10.java >>>>>>>> --- a/test/tools/javac/lambda/MostSpecific10.java >>>>>>>> +++ b/test/tools/javac/lambda/MostSpecific10.java >>>>>>>> @@ -26,8 +26,9 @@ >>>>>>>> * @bug 8034223 >>>>>>>> * @summary Structural most-specific logic for lambdas, method >>>>>>>> refs, >>>>>>>> parens, and conditionals >>>>>>>> * @compile MostSpecific10.java >>>>>>>> + * @run main MostSpecific10 >>>>>>>> */ >>>>>>>> -class MostSpecific10 { >>>>>>>> +public class MostSpecific10 { >>>>>>>> >>>>>>>> interface GetInt { >>>>>>>> int get(); >>>>>>>> @@ -38,7 +39,7 @@ >>>>>>>> } >>>>>>>> >>>>>>>> void m(GetInt getter) {} >>>>>>>> - void m(GetInteger getter) {} >>>>>>>> + void m(GetInteger getter) {throw new >>>>>>>> RuntimeException("Less-specific method invocation: " + >>>>>>>> getter.getClass());} >>>>>>>> >>>>>>>> void test(boolean cond) { >>>>>>>> m(() -> 23); >>>>>>>> @@ -50,5 +51,9 @@ >>>>>>>> m(cond ? (() -> 23) : ("abc"::length) ); >>>>>>>> m(( cond ? () -> 23 : cond ? ("abc"::length) : (() -> 23) >>>>>>>> )); >>>>>>>> } >>>>>>>> + >>>>>>>> + public static void main(String[] args) { >>>>>>>> + new MostSpecific10().test(true); >>>>>>>> + } >>>>>>>> >>>>>>>> } >>>>>>> >>>>>>> >>> >> > > > ------------------------------ > > Message: 6 > Date: Mon, 9 Jan 2017 16:02:13 -0800 > From: joe darcy > To: "compiler-dev at openjdk.java.net" > Subject: JDK 9 RFR of JDK-8172458: Make javax.lang.model javadoc HTML > 5 compliant > Message-ID: <8789276c-8cad-8d31-6435-02555cd470ba at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hello, > > The javadoc in javax.lang.model.* and javax.annotation.processing use > some constructs that are not HTML 5 compliant. These constructs should > be updated to be compliant with HTML 5, mostly replacing tags > with . Please review the proposed changes below: > > JDK-8172458: Make javax.lang.model javadoc HTML 5 compliant: > https://bugs.openjdk.java.net/browse/JDK-8172458 > webrev: http://cr.openjdk.java.net/~darcy/8172458.0/ > > Thanks, > > -Joe > > > > > End of compiler-dev Digest, Vol 117, Issue 3 > ******************************************** From joe.darcy at oracle.com Wed Jan 11 02:38:33 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 10 Jan 2017 18:38:33 -0800 Subject: JDK 9 RFR of JDK-8172531: Correct misstatements in javax.lang.model visitor documentation Message-ID: <3149ec1e-6adc-e271-bf7c-f7f52965fb47@oracle.com> Hello, Please review the selection of corrections and improvements to the javadoc of the visitor type of javax.lang.model in: JDK-8172531: Correct misstatements in javax.lang.model visitor documentation http://cr.openjdk.java.net/~darcy/8172531.0/ Description and guide to the changes: * For better readability, the notation "visitXYZ" is replaced with "visitXyz". * The visitor interface types in javax.lang.model.{element, type} have a change in verb tense to describe what was and was not done in Java SE 8. * In the utility visitors, a paragraph mentioning default methods is removed. * In the Kind visitor classes, the discussion of the when the kind methods are called uses a correct name "visitXyz*As*Kind" rather than the incorrect "visitXyzKind". Thanks, -Joe From istomin.den at gmail.com Thu Jan 12 16:14:49 2017 From: istomin.den at gmail.com (Denis Istomin) Date: Thu, 12 Jan 2017 21:14:49 +0500 Subject: [Patch] 8051768: Inconsistent output for Visible and InvisibleParameterAnnotations Message-ID: Hi, Made path fo bug 8051768 (see attachments). I realize that maybe it would be better not to but labels at the front of each line. But this patch makes output of javap more consistent and removes duplicate code. -- Denis Istomin -------------- next part -------------- # HG changeset patch # User istomin # Date 1484237512 -18000 # Thu Jan 12 21:11:52 2017 +0500 # Node ID 4b04eea6068da567daab88e5c6a34ef776cbfbd1 # Parent cfa0d90539072c6b5459846ecd89b8162e012d78 8051768: Fix output for Visible and InvisibleParameterAnnotations diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java b/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java --- a/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java @@ -56,6 +56,7 @@ import com.sun.tools.classfile.RuntimeInvisibleAnnotations_attribute; import com.sun.tools.classfile.RuntimeInvisibleParameterAnnotations_attribute; import com.sun.tools.classfile.RuntimeInvisibleTypeAnnotations_attribute; +import com.sun.tools.classfile.RuntimeParameterAnnotations_attribute; import com.sun.tools.classfile.RuntimeVisibleAnnotations_attribute; import com.sun.tools.classfile.RuntimeVisibleParameterAnnotations_attribute; import com.sun.tools.classfile.RuntimeVisibleTypeAnnotations_attribute; @@ -764,9 +765,8 @@ return null; } - @Override - public Void visitRuntimeVisibleParameterAnnotations(RuntimeVisibleParameterAnnotations_attribute attr, Void ignore) { - println("RuntimeVisibleParameterAnnotations:"); + private Void visitParameterAnnotations(String message, RuntimeParameterAnnotations_attribute attr) { + println(message); indent(+1); for (int param = 0; param < attr.parameter_annotations.length; param++) { println("parameter " + param + ": "); @@ -781,23 +781,15 @@ indent(-1); return null; } + + @Override + public Void visitRuntimeVisibleParameterAnnotations(RuntimeVisibleParameterAnnotations_attribute attr, Void ignore) { + return visitParameterAnnotations("RuntimeVisibleParameterAnnotations:", (RuntimeParameterAnnotations_attribute) attr); + } @Override public Void visitRuntimeInvisibleParameterAnnotations(RuntimeInvisibleParameterAnnotations_attribute attr, Void ignore) { - println("RuntimeInvisibleParameterAnnotations:"); - indent(+1); - for (int param = 0; param < attr.parameter_annotations.length; param++) { - println(param + ": "); - indent(+1); - for (int i = 0; i < attr.parameter_annotations[param].length; i++) { - print(i + ": "); - annotationWriter.write(attr.parameter_annotations[param][i]); - println(); - } - indent(-1); - } - indent(-1); - return null; + return visitParameterAnnotations("RuntimeInvisibleParameterAnnotations:", (RuntimeParameterAnnotations_attribute) attr); } @Override diff --git a/test/tools/javap/InvisibleParameterAnnotationsTest.java b/test/tools/javap/InvisibleParameterAnnotationsTest.java new file mode 100644 --- /dev/null +++ b/test/tools/javap/InvisibleParameterAnnotationsTest.java @@ -0,0 +1,78 @@ +/* + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8051768 + * @summary Verify that javap prints "param" for RuntimeInvisibleParameterAnnotations + * @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 InvisibleParameterAnnotationsTest + */ + +import toolbox.JavacTask; +import toolbox.JavapTask; +import toolbox.Task; +import toolbox.ToolBox; + +public class InvisibleParameterAnnotationsTest { + + private static final String TestSrc = + "import java.lang.annotation.Retention \n;" + + "import java.lang.annotation.RetentionPolicy \n;" + + + "public class Sample { \n" + + + "@Retention(RetentionPolicy.CLASS) \n" + + "public @interface InvisAnno{} \n" + + "@Retention(RetentionPolicy.RUNTIME) \n" + + "public @interface VisAnno{} \n" + + + "public void Method(@InvisAnno int arg1, at VisAnno int arg2){};" + + "}"; + + private static final String ExpectedSubstring = + " RuntimeVisibleParameterAnnotations:\n" + + " parameter 0:\n" + + " parameter 1:\n" + + " 0: #16()\n" + + " RuntimeInvisibleParameterAnnotations:\n" + + " parameter 0:\n" + + " 0: #18()\n" + + " parameter 1:"; + + public static void main(String[] args) throws Exception { + ToolBox tb = new ToolBox(); + new JavacTask(tb).sources(TestSrc).run(); + + Task.Result res = new JavapTask(tb).options("-v").classes("Sample.class").run(); + + String outString = res.getOutput(Task.OutputKind.DIRECT); + if (!outString.contains(ExpectedSubstring)) { + throw new Error("Error"); + } + } +} From cushon at google.com Thu Jan 12 19:23:50 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 12 Jan 2017 11:23:50 -0800 Subject: RFR 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage In-Reply-To: References: <586C5753.903@oracle.com> Message-ID: Any more thoughts on this? I'm happy to revise the approach if there's a better way to use the hint. On Tue, Jan 3, 2017 at 10:28 PM, Liam Miller-Cushon wrote: > Thanks for the feedback, > > On Tue, Jan 3, 2017 at 9:00 PM, Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> I guess I am slightly surprised by the proposed solution, as regards the >> choice of what it means to find a match. I have always assumed that any >> implementation would iterate over the element values of the annotation, >> looking for a value that is .equals to the given value, for some >> appropriate definition of AnnotationValue.equals. It does not seem obvious >> to me that you should be searching within the individual element values for >> the match. I am also surprised that you might match for @B + 2; I would >> expect the annotation mirror to only match at the top level. For example, >> assuming a "first one wins" policy, I would have expected @B + 2 to match >> the second annotation in the pair of annotations `@A(x = {1}, y = @B(2)) >> @B(2)` > > > I thought the proposed approach was consistent with the existing handling > of AnnotationMirror. The overloads of matchAnnoToTree use reference > equality to find a matching AnnotationMirror, which could be either a > top-level or nested annotation on the element. So given `@A(x = {1}, y = > @B(2)) @B(2)`, passing an AnnotationMirror for @B to printMessage(..., > Element, AnnotationMirror) could match either appearance of @B depending on > which instance the argument was. > > Is there a definition of AnnotationValue.equals that would be more > appropriate than reference equality? Value equality would be ambiguous for > e.g. `@A(x=1, y=1, z=1)` and @A + 1. > > The motivation for supporting array elements was the same one mentioned in > the bug [1], which I've heard repeated elsewhere: for annotations > containing large array initializers it'd be helpful to place the caret at a > specific element instead of the start of the array. > > Liam > > [1] https://bugs.openjdk.java.net/browse/JDK-6388543? > focusedCommentId=12267020&page=com.atlassian.jira. > plugin.system.issuetabpanels:comment-tabpanel#comment-12267020 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Thu Jan 12 19:55:06 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 12 Jan 2017 11:55:06 -0800 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: <5877DF1A.2060508@oracle.com> On 11/3/2016 4:24 PM, Alex Buckley wrote: > 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]. Filed JDK-8172742 to track this issue post-9. Alex From jonathan.gibbons at oracle.com Thu Jan 12 21:46:09 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 Jan 2017 13:46:09 -0800 Subject: RFR 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage In-Reply-To: References: <586C5753.903@oracle.com> Message-ID: <5877F921.80803@oracle.com> Hi Liam, I have reviewed the spec for the method, the existing code, the bug report and its comments, and your notes in this email thread. I note that reference equality is being used, and I agree it seems to give the best semantics, as regards avoiding ambiguities. I also note that the search for the annotation mirror is recursive. Although not functionally necessary, this makes me wonder whether we should not also search recursively for the annotation value. That would seem to give the best flexibility to the user, allowing them to find a match for @A + 2, to use the example in this thread. Is there any good reason not to do so? -- Jon On 01/12/2017 11:23 AM, Liam Miller-Cushon wrote: > Any more thoughts on this? I'm happy to revise the approach if there's > a better way to use the hint. > > On Tue, Jan 3, 2017 at 10:28 PM, Liam Miller-Cushon > wrote: > > Thanks for the feedback, > > On Tue, Jan 3, 2017 at 9:00 PM, Jonathan Gibbons > > > wrote: > > I guess I am slightly surprised by the proposed solution, as > regards the choice of what it means to find a match. I have > always assumed that any implementation would iterate over the > element values of the annotation, looking for a value that is > .equals to the given value, for some appropriate definition of > AnnotationValue.equals. It does not seem obvious to me that > you should be searching within the individual element values > for the match. I am also surprised that you might match for @B > + 2; I would expect the annotation mirror to only match at the > top level. For example, assuming a "first one wins" policy, > I would have expected @B + 2 to match the second annotation in > the pair of annotations `@A(x = {1}, y = @B(2)) @B(2)` > > > I thought the proposed approach was consistent with the existing > handling of AnnotationMirror. The overloads of matchAnnoToTree use > reference equality to find a matching AnnotationMirror, which > could be either a top-level or nested annotation on the element. > So given `@A(x = {1}, y = @B(2)) @B(2)`, passing an > AnnotationMirror for @B to printMessage(..., Element, > AnnotationMirror) could match either appearance of @B depending on > which instance the argument was. > > Is there a definition of AnnotationValue.equals that would be more > appropriate than reference equality? Value equality would be > ambiguous for e.g. `@A(x=1, y=1, z=1)` and @A + 1. > > The motivation for supporting array elements was the same one > mentioned in the bug [1], which I've heard repeated elsewhere: for > annotations containing large array initializers it'd be helpful to > place the caret at a specific element instead of the start of the > array. > > Liam > > [1] > https://bugs.openjdk.java.net/browse/JDK-6388543?focusedCommentId=12267020&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12267020 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Fri Jan 13 07:18:27 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 13 Jan 2017 08:18:27 +0100 (CET) Subject: [Patch] 8051768: Inconsistent output for Visible and InvisibleParameterAnnotations In-Reply-To: References: Message-ID: <487145553.1847977.1484291907043.JavaMail.zimbra@u-pem.fr> Hi denis, nice patch, you can use void instead of Void when declaring the private method visitParameterAnnotations. R?mi ----- Mail original ----- > De: "Denis Istomin" > ?: compiler-dev at openjdk.java.net > Envoy?: Jeudi 12 Janvier 2017 17:14:49 > Objet: [Patch] 8051768: Inconsistent output for Visible and InvisibleParameterAnnotations > Hi, > Made path fo bug 8051768 (see attachments). > I realize that maybe it would be better not to but labels at the front > of each line. But this patch makes output of javap more consistent and > removes duplicate code. > > -- > Denis Istomin From jan.lahoda at oracle.com Fri Jan 13 11:14:26 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 13 Jan 2017 12:14:26 +0100 Subject: long classpaths and JDK-8162492 In-Reply-To: References: Message-ID: <5878B692.7060308@oracle.com> Hi Liam, On 15.12.2016 05:13, Liam Miller-Cushon wrote: > Thanks for investigating! I went ahead and filed > https://bugs.openjdk.java.net/browse/JDK-8171294 with the repro. > > And here's a prototype of eager scanning: > http://cr.openjdk.java.net/~cushon/8171294/webrev.00/. We have been looking at several approaches to improve the situation (all based on removing the pathCache), including speeding up zipfs and our access to it. In your patch, if I understand it correctly, PathFileObjects are created eagerly. That might be of a concern regarding memory use. Some time ago, Maurizio put together a patch that constructs just a cache of packages in a given jar file: http://cr.openjdk.java.net/~jlahoda/8171294/webrev-cache-packages/ That seems to bring times on the testcase back to JDK 8 levels. Among other patches, this one currently appears as the most viable one. Is there a chance you could try to see if it fixes the problem for you as well? Thanks! Jan > > On Wed, Dec 14, 2016 at 3:43 AM, Claes Redestad > > wrote: > > Thanks for the report and reproducer. > > I took it for a spin and analyzed behavior for bit, and in additional > to a massive amount of calls to Files.exist (which would be avoided > by actually scanning eagerly), the current design also has a problem > with rampant retained set growth (quadratic, it seems), which leads to > GC thrashing (and would eventually have javac crash with an OOM on > a long enough classpath). > > This is easily seen by running with -J-Xlog:gc > > [7.161s][info][gc] GC(31) Pause Young (G1 Evacuation Pause) > 403M->132M(911M) 38.814ms > [7.925s][info][gc] GC(32) Pause Young (G1 Evacuation Pause) > 295M->137M(911M) 50.975ms > ... > [76.455s][info][gc] GC(80) Pause Young (G1 Evacuation Pause) > 1026M->778M(6102M) 191.624ms > [78.020s][info][gc] GC(81) Pause Young (G1 Evacuation Pause) > 1057M->784M(6102M) 164.749ms > > real 11m11.944s > user 98m15.140s > sys 1m19.092s > > Not caching the failed lookup at all[1] leads to a much slower growth > rate for the retained set and a quicker execution overall: > > [21.354s][info][gc] GC(39) Pause Young (G1 Evacuation Pause) > 515M->88M(726M) 12.811ms > [22.727s][info][gc] GC(40) Pause Young (G1 Evacuation Pause) > 514M->88M(726M) 14.445ms > ... > [75.846s][info][gc] GC(79) Pause Young (G1 Evacuation Pause) > 622M->108M(872M) 20.874ms > [77.391s][info][gc] GC(80) Pause Young (G1 Evacuation Pause) > 623M->109M(872M) 17.676ms > > real 7m3.745s > user 8m34.560s > sys 0m5.040s > > Not saying this[1] is anywhere near a good final solution, but helps to > underscore that this might be more critical than a simple > corner-case performance bug. > > Thanks! > > /Claes > > [1] > diff -r 50135a630f35 > src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java > --- > a/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java > Tue Dec 13 12:25:58 2016 -0800 > +++ > b/src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java > Wed Dec 14 12:39:52 2016 +0100 > @@ -586,7 +586,7 @@ > Path relativePath = path.resolveAgainst(fileSystem); > > if (!Files.exists(relativePath)) { > - relativePath = null; > + return null; > } > > pathCache.put(path, relativePath); > > > > On 2016-12-13 05:18, Liam Miller-Cushon wrote: > > I noticed a performance regression with long classpaths and large > numbers of sources. This is related to JDK-8162492, but the > benchmarks > in that bug are for long classpaths with a single source file, > and my > proposed fix doesn't address that. > > Under JDK 9 I'm seeing compilation time scale as the product of the > classpath length and the number of calls to getFileObject or > list. The > example below takes 17s with JDK 8 and 8m40s with JDK 9. > > I think the issue is with the cache strategy in ArchiveContainer. > ArchiveContainer calls Files.exists for each path and caches the > result, > but if it's queried for a large number of distinct paths it > doesn't get > cache hits, and ends up doing a lot of work. > > I'd like to propose bringing back the cache strategy that was > used in > ZipArchive: > http://hg.openjdk.java.net/jdk8/jdk8/langtools/file/1ff9d5118aae/src/share/classes/com/sun/tools/javac/file/ZipArchive.java#l73 > . > ZipArchive scans all entries in the zip once, and puts the directory > names in a cache. If getFileObject/list are called many times > with paths > that aren't in the archive it doesn't have to do any work, and > the cache > stays small. > > I have a couple of question about how to proceed: > > - does bringing back the ZipArchive-style cache sound > reasonable, or are > there other advantages to the new approach used in ArchiveContainer? > > - should I add this to JDK-8162492, or does it deserve a > separate bug? > > > Here's the repro - > > generate the test inputs (start in a fresh directory): > > $ javac -cp asm.jar Test.java && java -cp asm.jar:. Test > > compile: > > $ $JAVAC8 -fullversion > javac full version "1.8.0_122-ea-b04" > $ time $JAVAC8 @params.txt > real0m17.385s > user0m40.855s > sys0m1.305s > > $ $JAVAC9 -fullversion > javac full version "9-ea+148" > $ time $JAVAC9 @params.txt > real8m40.530s > user32m8.614s > sys0m57.024s > > === Test.java === > import static java.nio.charset.StandardCharsets.UTF_8; > import static org.objectweb.asm.Opcodes.ACC_PUBLIC; > import static org.objectweb.asm.Opcodes.ACC_SUPER; > > import java.io.File; > import java.nio.file.Files; > import java.nio.file.Paths; > import java.util.ArrayList; > import java.util.List; > import java.util.jar.JarEntry; > import java.util.jar.JarOutputStream; > import org.objectweb.asm.ClassWriter; > > class Test { > > static final int JARS = 1000; > static final int CLASSES = 100; > static final int SOURCES = 1000; > > public static void main(String[] args) throws Exception { > List jars = new ArrayList<>(); > for (int i = 0; i < JARS; i++) { > String jarName = "lib" + i + ".jar"; > jars.add(jarName); > try (JarOutputStream jos = > new > JarOutputStream(Files.newOutputStream(Paths.get(jarName)))) { > for (int j = 0; j < CLASSES; j++) { > String name = String.format("b%d%d/B%d%d", > i, j, i, j); > jos.putNextEntry(new JarEntry(name + > ".class")); > ClassWriter cw = new ClassWriter(0); > cw.visit(52, ACC_PUBLIC | ACC_SUPER, name, > null, > "java/lang/Object", null); > jos.write(cw.toByteArray()); > } > } > } > List sources = new ArrayList<>(); > for (int i = 0; i < SOURCES; i++) { > StringBuilder sb = new StringBuilder(); > sb.append(String.format("package a%d;\n", i)); > sb.append(String.format("class A%d {\n", i)); > for (int j = 0; j < CLASSES; j++) { > String name = String.valueOf((i + j) % JARS) + j; > sb.append(String.format("b%s.B%s x%d;\n", name, > name, j)); > } > sb.append(" }\n"); > String file = String.format("A%d.java", i, i); > sources.add(file); > Files.write(Paths.get(file), > sb.toString().getBytes(UTF_8)); > } > List params = new ArrayList<>(); > params.addAll(sources); > params.add("-cp"); > params.add(String.join(File.pathSeparator, jars)); > Files.write(Paths.get("params.txt"), params, UTF_8); > } > } > === > > From bsrbnd at gmail.com Fri Jan 13 13:01:26 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 13 Jan 2017 14:01:26 +0100 Subject: Incoherent invocation type inference? Message-ID: Hi, I encountered a strange behavior in the the case of a poly expression method invocation (with 'null' or without parameter) that doesn't provide any explicit type argument (JLS 18.5.2). The following code: import java.util.*; public class Issue { > T get() { return (T)new ArrayList(); } > T get(T t) { return (T)new ArrayList(); } void run() { List li = null; LinkedList ll = null; Integer i = null; li = get(null); i = get(null); // Shouldn't compile? and will fail at runtime. // i = get(li); // Fails as expected li = get(); ll = get(); // OK, but will fail at runtime due to unchecked conversion in get(). i = get(); // Shouldn't compile? and will fail at runtime. } public static void main(String... args) { new Issue().run(); } } ...is translated as follows before code generation: public class Issue { public Issue() { super(); } Iterable get() { return (Iterable)new ArrayList(); } Iterable get(Iterable t) { return (Iterable)new ArrayList(); } void run() { List li = null; LinkedList ll = null; Integer i = null; li = (List)get(null); i = (Integer)get(null); li = (List)get(); ll = (LinkedList)get(); i = (Integer)get(); } public static void main(String... args) { new Issue().run(); } } The next line is OK, but will fail at runtime due to unchecked converstion in get(): ll = (LinkedList)get(); But the following lines are more surprising: i = (Integer)get(null); i = (Integer)get(); They will, of course, fail at runtime with ClassCastException. I think that javac behavior is probably in compliance with JLS 18.5.2, but is this really coherent? Thanks, Bernard From maurizio.cimadamore at oracle.com Fri Jan 13 14:12:35 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 13 Jan 2017 14:12:35 +0000 Subject: Incoherent invocation type inference? In-Reply-To: References: Message-ID: I think that's correct behavior. When you say something like: li = get(null); T will get two constraints: * an upper bound (from declared bound) : T <: Iterable * an upper bound (from return type compatibility) : T <: Integer The language will then infer T = Integer & Iterable, an intersection type. Normally this would be fine - but the issue here is that Integer is a final class, so that intersection type has no witnesses - e.g. there's no way for get() to construct a type that is both an Integer and an Iterable - so that will almost always fail - unless get() returns null. That said, I'm not aware of any check in the spec for preventing an intersection type to mention a final class as one of its components so, while this does look weird, I think the compiler is doing what the language spec says. Maurizio On 13/01/17 13:01, B. Blaser wrote: > mport java.util.*; > > public class Issue { > > T get() { return (T)new ArrayList(); } > > T get(T t) { return (T)new > ArrayList(); } > > void run() { > List li = null; > LinkedList ll = null; > Integer i = null; > > li = get(null); > i = get(null); // Shouldn't compile? and will fail at runtime. > // i = get(li); // Fails as expected > > li = get(); > ll = get(); // OK, but will fail at runtime due to unchecked > conversion in get(). > i = get(); // Shouldn't compile? and will fail at runtime. > } > > public static void main(String... args) { > new Issue().run(); > } > } From forax at univ-mlv.fr Fri Jan 13 14:50:11 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 13 Jan 2017 15:50:11 +0100 (CET) Subject: Incoherent invocation type inference? In-Reply-To: References: Message-ID: <1183117412.2135183.1484319011263.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "B. Blaser" , compiler-dev at openjdk.java.net > Envoy?: Vendredi 13 Janvier 2017 15:12:35 > Objet: Re: Incoherent invocation type inference? > I think that's correct behavior. When you say something like: > > li = get(null); > > > T will get two constraints: > > * an upper bound (from declared bound) : T <: Iterable > * an upper bound (from return type compatibility) : T <: Integer > > The language will then infer T = Integer & Iterable, an > intersection type. > > Normally this would be fine - but the issue here is that Integer is a > final class, so that intersection type has no witnesses - e.g. there's > no way for get() to construct a type that is both an Integer and an > Iterable - so that will almost always fail - unless get() > returns null. > > That said, I'm not aware of any check in the spec for preventing an > intersection type to mention a final class as one of its components so, > while this does look weird, I think the compiler is doing what the > language spec says. The spec can not use the fact that a class is final because it's a source and binary compatible change to remove final for a class. You will break the encapsulation if the class is used by another class but that's another story. > > Maurizio > R?mi > > On 13/01/17 13:01, B. Blaser wrote: >> mport java.util.*; >> >> public class Issue { >> > T get() { return (T)new ArrayList(); } >> > T get(T t) { return (T)new >> ArrayList(); } >> >> void run() { >> List li = null; >> LinkedList ll = null; >> Integer i = null; >> >> li = get(null); >> i = get(null); // Shouldn't compile? and will fail at runtime. >> // i = get(li); // Fails as expected >> >> li = get(); >> ll = get(); // OK, but will fail at runtime due to unchecked >> conversion in get(). >> i = get(); // Shouldn't compile? and will fail at runtime. >> } >> >> public static void main(String... args) { >> new Issue().run(); >> } > > } From istomin.den at gmail.com Fri Jan 13 16:59:06 2017 From: istomin.den at gmail.com (Denis Istomin) Date: Fri, 13 Jan 2017 21:59:06 +0500 Subject: [Patch] 8051768: Inconsistent output for Visible and InvisibleParameterAnnotations In-Reply-To: <487145553.1847977.1484291907043.JavaMail.zimbra@u-pem.fr> References: <487145553.1847977.1484291907043.JavaMail.zimbra@u-pem.fr> Message-ID: Fixed using Void at private method declaration. -- Denis Istomin 2017-01-13 12:18 GMT+05:00 Remi Forax : > Hi denis, > nice patch, > you can use void instead of Void when declaring the private method visitParameterAnnotations. > > R?mi > > ----- Mail original ----- >> De: "Denis Istomin" >> ?: compiler-dev at openjdk.java.net >> Envoy?: Jeudi 12 Janvier 2017 17:14:49 >> Objet: [Patch] 8051768: Inconsistent output for Visible and InvisibleParameterAnnotations > >> Hi, >> Made path fo bug 8051768 (see attachments). >> I realize that maybe it would be better not to but labels at the front >> of each line. But this patch makes output of javap more consistent and >> removes duplicate code. >> >> -- >> Denis Istomin -------------- next part -------------- # HG changeset patch # User istomin # Date 1484324910 -18000 # Fri Jan 13 21:28:30 2017 +0500 # Node ID 5dd6058a1eff3b2091addb3805baf053fcef6793 # Parent cfa0d90539072c6b5459846ecd89b8162e012d78 8051768: Fix output for Visible and InvisibleParameterAnnotations diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java b/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java --- a/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java @@ -56,6 +56,7 @@ import com.sun.tools.classfile.RuntimeInvisibleAnnotations_attribute; import com.sun.tools.classfile.RuntimeInvisibleParameterAnnotations_attribute; import com.sun.tools.classfile.RuntimeInvisibleTypeAnnotations_attribute; +import com.sun.tools.classfile.RuntimeParameterAnnotations_attribute; import com.sun.tools.classfile.RuntimeVisibleAnnotations_attribute; import com.sun.tools.classfile.RuntimeVisibleParameterAnnotations_attribute; import com.sun.tools.classfile.RuntimeVisibleTypeAnnotations_attribute; @@ -764,9 +765,8 @@ return null; } - @Override - public Void visitRuntimeVisibleParameterAnnotations(RuntimeVisibleParameterAnnotations_attribute attr, Void ignore) { - println("RuntimeVisibleParameterAnnotations:"); + private void visitParameterAnnotations(String message, RuntimeParameterAnnotations_attribute attr) { + println(message); indent(+1); for (int param = 0; param < attr.parameter_annotations.length; param++) { println("parameter " + param + ": "); @@ -779,24 +779,17 @@ indent(-1); } indent(-1); + } + + @Override + public Void visitRuntimeVisibleParameterAnnotations(RuntimeVisibleParameterAnnotations_attribute attr, Void ignore) { + visitParameterAnnotations("RuntimeVisibleParameterAnnotations:", (RuntimeParameterAnnotations_attribute) attr); return null; } @Override public Void visitRuntimeInvisibleParameterAnnotations(RuntimeInvisibleParameterAnnotations_attribute attr, Void ignore) { - println("RuntimeInvisibleParameterAnnotations:"); - indent(+1); - for (int param = 0; param < attr.parameter_annotations.length; param++) { - println(param + ": "); - indent(+1); - for (int i = 0; i < attr.parameter_annotations[param].length; i++) { - print(i + ": "); - annotationWriter.write(attr.parameter_annotations[param][i]); - println(); - } - indent(-1); - } - indent(-1); + visitParameterAnnotations("RuntimeInvisibleParameterAnnotations:", (RuntimeParameterAnnotations_attribute) attr); return null; } diff --git a/test/tools/javap/InvisibleParameterAnnotationsTest.java b/test/tools/javap/InvisibleParameterAnnotationsTest.java new file mode 100644 --- /dev/null +++ b/test/tools/javap/InvisibleParameterAnnotationsTest.java @@ -0,0 +1,78 @@ +/* + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8051768 + * @summary Verify that javap prints "param" for RuntimeInvisibleParameterAnnotations + * @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 InvisibleParameterAnnotationsTest + */ + +import toolbox.JavacTask; +import toolbox.JavapTask; +import toolbox.Task; +import toolbox.ToolBox; + +public class InvisibleParameterAnnotationsTest { + + private static final String TestSrc = + "import java.lang.annotation.Retention \n;" + + "import java.lang.annotation.RetentionPolicy \n;" + + + "public class Sample { \n" + + + "@Retention(RetentionPolicy.CLASS) \n" + + "public @interface InvisAnno{} \n" + + "@Retention(RetentionPolicy.RUNTIME) \n" + + "public @interface VisAnno{} \n" + + + "public void Method(@InvisAnno int arg1, at VisAnno int arg2){};" + + "}"; + + private static final String ExpectedSubstring = + " RuntimeVisibleParameterAnnotations:\n" + + " parameter 0:\n" + + " parameter 1:\n" + + " 0: #16()\n" + + " RuntimeInvisibleParameterAnnotations:\n" + + " parameter 0:\n" + + " 0: #18()\n" + + " parameter 1:"; + + public static void main(String[] args) throws Exception { + ToolBox tb = new ToolBox(); + new JavacTask(tb).sources(TestSrc).run(); + + Task.Result res = new JavapTask(tb).options("-v").classes("Sample.class").run(); + + String outString = res.getOutput(Task.OutputKind.DIRECT); + if (!outString.contains(ExpectedSubstring)) { + throw new Error("Error"); + } + } +} From joe.darcy at oracle.com Fri Jan 13 19:34:01 2017 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 13 Jan 2017 11:34:01 -0800 Subject: JDK 9 RFR of JDK-8172686: Use less aggressive deprecation of utility visitors Message-ID: Hello, As part of JDK-8050430, the Java SE 6 vintage utility visitors in javax.lang.model.util were deprecated. This deprecation is a bit overly aggressive; deprecating the constructors of the utility visitors would suffice. Please review the changes to do this: http://cr.openjdk.java.net/~darcy/8172686.0/ (I'll change the copyright years to 2017 before pushing.) Thanks, -Joe From istomin.den at gmail.com Fri Jan 13 21:38:56 2017 From: istomin.den at gmail.com (Denis Istomin) Date: Sat, 14 Jan 2017 02:38:56 +0500 Subject: [Patch] 8041793: javap misses newline after printing AnnotationDefault Message-ID: Hi, Made patch for bug 8041793. -- Denis Istomin -------------- next part -------------- # HG changeset patch # User istomin # Date 1484343294 -18000 # Sat Jan 14 02:34:54 2017 +0500 # Node ID dc10134e8d6f51bbd476fcb3ff32eedd93738329 # Parent cfa0d90539072c6b5459846ecd89b8162e012d78 8041793: javap misses newline after printing AnnotationDefault diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java b/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java --- a/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java @@ -164,6 +164,7 @@ print("default_value: "); annotationWriter.write(attr.default_value); indent(-1); + println(); return null; } diff --git a/test/tools/javap/typeAnnotations/AnnotationDefaultNewlineTest.java b/test/tools/javap/typeAnnotations/AnnotationDefaultNewlineTest.java new file mode 100644 --- /dev/null +++ b/test/tools/javap/typeAnnotations/AnnotationDefaultNewlineTest.java @@ -0,0 +1,64 @@ +/* + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8041793 + * @summary Verify that javap prints newline character after AnnotationDefault value + * @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 AnnotationDefaultNewlineTest + */ + +import toolbox.JavacTask; +import toolbox.JavapTask; +import toolbox.Task; +import toolbox.ToolBox; + +public class AnnotationDefaultNewlineTest { + + private static final String TestSrc = + "public @interface AnnotationDefault { \n" + + "public abstract int value() default 1; \n" + + "}"; + + private static final String ExpectedSubstring = + " AnnotationDefault:\n" + + " default_value: I#7\n"; + + public static void main(String[] args) throws Exception { + ToolBox tb = new ToolBox(); + new JavacTask(tb).sources(TestSrc).run(); + + Task.Result res = new JavapTask(tb).options("-v").classes("AnnotationDefault.class").run(); + + String outString = res.getOutput(Task.OutputKind.DIRECT); + System.out.println(outString); + if (!outString.contains(ExpectedSubstring)) { + throw new Error("Error"); + } + } +} From bsrbnd at gmail.com Fri Jan 13 21:58:11 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 13 Jan 2017 22:58:11 +0100 Subject: Incoherent invocation type inference? In-Reply-To: References: Message-ID: Hi, 2017-01-13 15:12 GMT+01:00 Maurizio Cimadamore : > I think that's correct behavior. When you say something like: > > li = get(null); i = get(null); // li = ... is OK ;-) > T will get two constraints: > > * an upper bound (from declared bound) : T <: Iterable > * an upper bound (from return type compatibility) : T <: Integer Integer being final, a correct return type constraint would be , leading to incompatible bounds {T <: Iterable, } and then javac should fail...? Bernard > The language will then infer T = Integer & Iterable, an intersection > type. > > Normally this would be fine - but the issue here is that Integer is a final > class, so that intersection type has no witnesses - e.g. there's no way for > get() to construct a type that is both an Integer and an Iterable - > so that will almost always fail - unless get() returns null. > > That said, I'm not aware of any check in the spec for preventing an > intersection type to mention a final class as one of its components so, > while this does look weird, I think the compiler is doing what the language > spec says. > > Maurizio > > > > On 13/01/17 13:01, B. Blaser wrote: >> >> mport java.util.*; >> >> public class Issue { >> > T get() { return (T)new >> ArrayList(); } >> > T get(T t) { return (T)new >> ArrayList(); } >> >> void run() { >> List li = null; >> LinkedList ll = null; >> Integer i = null; >> >> li = get(null); >> i = get(null); // Shouldn't compile? and will fail at runtime. >> // i = get(li); // Fails as expected >> >> li = get(); >> ll = get(); // OK, but will fail at runtime due to unchecked >> conversion in get(). >> i = get(); // Shouldn't compile? and will fail at runtime. >> } >> >> public static void main(String... args) { >> new Issue().run(); >> } >> } > > From jonathan.gibbons at oracle.com Fri Jan 13 23:44:29 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 Jan 2017 15:44:29 -0800 Subject: JDK 9 RFR of JDK-8172686: Use less aggressive deprecation of utility visitors In-Reply-To: References: Message-ID: <5879665D.8070901@oracle.com> Joe, Looks good, -- Jon On 01/13/2017 11:34 AM, joe darcy wrote: > Hello, > > As part of JDK-8050430, the Java SE 6 vintage utility visitors in > javax.lang.model.util were deprecated. This deprecation is a bit > overly aggressive; deprecating the constructors of the utility > visitors would suffice. > > Please review the changes to do this: > > http://cr.openjdk.java.net/~darcy/8172686.0/ > > (I'll change the copyright years to 2017 before pushing.) > > Thanks, > > -Joe > From maurizio.cimadamore at oracle.com Sat Jan 14 00:42:05 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sat, 14 Jan 2017 00:42:05 +0000 Subject: Incoherent invocation type inference? In-Reply-To: References: Message-ID: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> On 13/01/17 21:58, B. Blaser wrote: > Hi, > > 2017-01-13 15:12 GMT+01:00 Maurizio Cimadamore : >> I think that's correct behavior. When you say something like: >> >> li = get(null); > i = get(null); // li = ... is OK ;-) > >> T will get two constraints: >> >> * an upper bound (from declared bound) : T <: Iterable >> * an upper bound (from return type compatibility) : T <: Integer > Integer being final, a correct return type constraint would be Integer>, leading to incompatible bounds {T <: Iterable, Integer>} and then javac should fail...? Well, if the spec would ever add some special treatment for finality in inference constraints (for instance cast conversion special cases final classes to give better results), that woul dbe a way yes - but I'll leave it to our spec experts. In your examples though, what's really troublesome, is that you have a generic method whose type-arguments are only instantiated from the return type constraint. When you have a situation like that, and you mix unchecked cast, things are going to blow up almost always - final or not. I'd be more supportive for an optional Lint warning for cases where inference doesn't get any constraints from the actual arguments - just for a quick comparison, C# treats these cases as hard errors; that's not the way Java inference has been designed from the start, but that doesn't mean that we couldn't help programmers steer away from dubious generic methods (like your 0-ary get() method below). Maurizio > > Bernard > >> The language will then infer T = Integer & Iterable, an intersection >> type. >> >> Normally this would be fine - but the issue here is that Integer is a final >> class, so that intersection type has no witnesses - e.g. there's no way for >> get() to construct a type that is both an Integer and an Iterable - >> so that will almost always fail - unless get() returns null. >> >> That said, I'm not aware of any check in the spec for preventing an >> intersection type to mention a final class as one of its components so, >> while this does look weird, I think the compiler is doing what the language >> spec says. >> >> Maurizio >> >> >> >> On 13/01/17 13:01, B. Blaser wrote: >>> mport java.util.*; >>> >>> public class Issue { >>> > T get() { return (T)new >>> ArrayList(); } >>> > T get(T t) { return (T)new >>> ArrayList(); } >>> >>> void run() { >>> List li = null; >>> LinkedList ll = null; >>> Integer i = null; >>> >>> li = get(null); >>> i = get(null); // Shouldn't compile? and will fail at runtime. >>> // i = get(li); // Fails as expected >>> >>> li = get(); >>> ll = get(); // OK, but will fail at runtime due to unchecked >>> conversion in get(). >>> i = get(); // Shouldn't compile? and will fail at runtime. >>> } >>> >>> public static void main(String... args) { >>> new Issue().run(); >>> } >>> } >> From joe.darcy at oracle.com Sat Jan 14 00:52:53 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 13 Jan 2017 16:52:53 -0800 Subject: JDK 9 RFR of JDK-8172686: Use less aggressive deprecation of utility visitors In-Reply-To: <5879665D.8070901@oracle.com> References: <5879665D.8070901@oracle.com> Message-ID: <58797665.9060206@oracle.com> Thanks Jon. Off-list, Stuart, aka Dr. Deprecator, pointed that the this @Deprecated tags do not have the since="9" information. While such information generally should be present on at least new-in-9 deprecations, these particular classes are compiled by the bootstrap JDK (JDK 8 currently) whose java.lang.Deprecation does not have a since method. I've filed the follow-up bug JDK-8172818: Add since=9 deprecation information to javax.lang.model classes to be fixed in JDK 10. Cheers, -Joe On 1/13/2017 3:44 PM, Jonathan Gibbons wrote: > Joe, > > Looks good, > > -- Jon > > On 01/13/2017 11:34 AM, joe darcy wrote: >> Hello, >> >> As part of JDK-8050430, the Java SE 6 vintage utility visitors in >> javax.lang.model.util were deprecated. This deprecation is a bit >> overly aggressive; deprecating the constructors of the utility >> visitors would suffice. >> >> Please review the changes to do this: >> >> http://cr.openjdk.java.net/~darcy/8172686.0/ >> >> (I'll change the copyright years to 2017 before pushing.) >> >> Thanks, >> >> -Joe >> > From jonathan.gibbons at oracle.com Sat Jan 14 02:50:24 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 Jan 2017 18:50:24 -0800 Subject: [Patch] 8041793: javap misses newline after printing AnnotationDefault In-Reply-To: References: Message-ID: <587991F0.8070904@oracle.com> On 01/13/2017 01:38 PM, Denis Istomin wrote: > Hi, > Made patch for bug 8041793. > Hi Denis, The test will probably fail on Windows, because you are checking for the exact newline character "\n". There are two typical solutions to this general problem. 1. Take the string returned by the tool and normalize the newlines with code similar to out.replace(System.getProperty("line.separator"), "\n") The system property is also available as a constant within the ToolBox class. 2. Split the output into lines, perhaps by using the getOutputLines method instead of getOutput, and then compare the resulting list against an equivalent list for the expected output. Note there are occasions when it is important to verify that the exact platform line separator sequence is being used, and that will require different solutions. Your test is also somewhat terse, in that in the case of a problem, it just says "Error". We run thousands of tests every day on JDK builds, and when a test fails, it is helpful to have a test report something more. In this case, saying "Expected output not found" would be slightly better, and probably good enough. In cases where the expected output is bigger, it becomes more helpful to give more details about where the mismatch occurs. You don't need to provide a full diff (!), but at least an indication of the line number of the first mismatch would help focus the attention of the person who ends up having to examine why the test failed. -- Jon From jonathan.gibbons at oracle.com Sat Jan 14 02:52:50 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 Jan 2017 18:52:50 -0800 Subject: [Patch] 8051768: Inconsistent output for Visible and InvisibleParameterAnnotations In-Reply-To: References: <487145553.1847977.1484291907043.JavaMail.zimbra@u-pem.fr> Message-ID: <58799282.6070905@oracle.com> On 01/13/2017 08:59 AM, Denis Istomin wrote: > Fixed using Void at private method declaration. Denis, Same comment as previous review, regarding newlines and terse error messages. -- Jon From jonathan.gibbons at oracle.com Sat Jan 14 02:57:47 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 Jan 2017 18:57:47 -0800 Subject: JDK 9 RFR of JDK-8172531: Correct misstatements in javax.lang.model visitor documentation In-Reply-To: <3149ec1e-6adc-e271-bf7c-f7f52965fb47@oracle.com> References: <3149ec1e-6adc-e271-bf7c-f7f52965fb47@oracle.com> Message-ID: <587993AB.7070402@oracle.com> Looks OK to me. -- Jon On 01/10/2017 06:38 PM, joe darcy wrote: > Hello, > > Please review the selection of corrections and improvements to the > javadoc of the visitor type of javax.lang.model in: > > JDK-8172531: Correct misstatements in javax.lang.model visitor > documentation > http://cr.openjdk.java.net/~darcy/8172531.0/ > > Description and guide to the changes: > > * For better readability, the notation "visitXYZ" is replaced with > "visitXyz". > > * The visitor interface types in javax.lang.model.{element, type} have > a change in verb tense to describe what was and was not done in Java > SE 8. > > * In the utility visitors, a paragraph mentioning default methods is > removed. > > * In the Kind visitor classes, the discussion of the when the kind > methods are called uses a correct name "visitXyz*As*Kind" rather than > the incorrect "visitXyzKind". > > Thanks, > > -Joe > From bsrbnd at gmail.com Sat Jan 14 13:12:51 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 14 Jan 2017 14:12:51 +0100 Subject: Incoherent invocation type inference? In-Reply-To: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> Message-ID: Hi, 2017-01-14 1:42 GMT+01:00 Maurizio Cimadamore : > > > On 13/01/17 21:58, B. Blaser wrote: >> >> Hi, >> >> 2017-01-13 15:12 GMT+01:00 Maurizio Cimadamore >> : >>> >>> I think that's correct behavior. When you say something like: >>> >>> li = get(null); >> >> i = get(null); // li = ... is OK ;-) >> >>> T will get two constraints: >>> >>> * an upper bound (from declared bound) : T <: Iterable >>> * an upper bound (from return type compatibility) : T <: Integer >> >> Integer being final, a correct return type constraint would be > Integer>, leading to incompatible bounds {T <: Iterable, > Integer>} and then javac should fail...? > > Well, if the spec would ever add some special treatment for finality in > inference constraints (for instance cast conversion special cases final > classes to give better results), that woul dbe a way yes - but I'll leave it > to our spec experts. In that case, I suggest something like below (line 899 in a more recent version). http://hg.openjdk.java.net/jdk9/dev/langtools/file/b6960e2da008/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#l899 > In your examples though, what's really troublesome, is that you have a > generic method whose type-arguments are only instantiated from the return > type constraint. When you have a situation like that, and you mix unchecked > cast, things are going to blow up almost always - final or not. I'd be more > supportive for an optional Lint warning for cases where inference doesn't > get any constraints from the actual arguments As unchecked cast produces a warning, javac should probably also emit at least a warning in our situation; but I'm not sure this would be really satisfying? Bernard diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java @@ -966,9 +966,11 @@ //if 's' is 'null' there's no instantiated type U for which //U <: s (but 'null' itself, which is not a valid type) return false; + } else if ((s.tsym.flags() & Flags.FINAL) != 0) { + t.addBound(InferenceBound.EQ, s, Types.this); + } else { + t.addBound(InferenceBound.UPPER, s, Types.this); } - - t.addBound(InferenceBound.UPPER, s, Types.this); return true; } > - just for a quick comparison, > C# treats these cases as hard errors; that's not the way Java inference has > been designed from the start, but that doesn't mean that we couldn't help > programmers steer away from dubious generic methods (like your 0-ary get() > method below). > > Maurizio > >> >> Bernard >> >>> The language will then infer T = Integer & Iterable, an >>> intersection >>> type. >>> >>> Normally this would be fine - but the issue here is that Integer is a >>> final >>> class, so that intersection type has no witnesses - e.g. there's no way >>> for >>> get() to construct a type that is both an Integer and an Iterable >>> - >>> so that will almost always fail - unless get() returns null. >>> >>> That said, I'm not aware of any check in the spec for preventing an >>> intersection type to mention a final class as one of its components so, >>> while this does look weird, I think the compiler is doing what the >>> language >>> spec says. >>> >>> Maurizio >>> >>> >>> >>> On 13/01/17 13:01, B. Blaser wrote: >>>> >>>> mport java.util.*; >>>> >>>> public class Issue { >>>> > T get() { return (T)new >>>> ArrayList(); } >>>> > T get(T t) { return (T)new >>>> ArrayList(); } >>>> >>>> void run() { >>>> List li = null; >>>> LinkedList ll = null; >>>> Integer i = null; >>>> >>>> li = get(null); >>>> i = get(null); // Shouldn't compile? and will fail at runtime. >>>> // i = get(li); // Fails as expected >>>> >>>> li = get(); >>>> ll = get(); // OK, but will fail at runtime due to unchecked >>>> conversion in get(). >>>> i = get(); // Shouldn't compile? and will fail at runtime. >>>> } >>>> >>>> public static void main(String... args) { >>>> new Issue().run(); >>>> } >>>> } >>> >>> > From cushon at google.com Sat Jan 14 23:37:00 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Sat, 14 Jan 2017 15:37:00 -0800 Subject: RFR 6388543: improve accuracy of source positions for AnnotationValue param of Messager.printMessage In-Reply-To: <5877F921.80803@oracle.com> References: <586C5753.903@oracle.com> <5877F921.80803@oracle.com> Message-ID: 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 cushon at google.com Sun Jan 15 02:03:52 2017 From: cushon at google.com (Liam Miller-Cushon) Date: Sat, 14 Jan 2017 18:03:52 -0800 Subject: long classpaths and JDK-8162492 In-Reply-To: <5878B692.7060308@oracle.com> References: <5878B692.7060308@oracle.com> Message-ID: On Fri, Jan 13, 2017 at 3:14 AM, Jan Lahoda wrote: > That seems to bring times on the testcase back to JDK 8 levels. Among > other patches, this one currently appears as the most viable one. Is there > a chance you could try to see if it fixes the problem for you as well? I tried out Maurizio's patch on the compilation that I first noticed this problem with. There was no significant difference in performance between the two approaches, and mine does use more memory. So that patch looks good to me. Thanks for the update! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Sun Jan 15 10:34:47 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 15 Jan 2017 11:34:47 +0100 Subject: Incoherent invocation type inference? In-Reply-To: References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> Message-ID: Hi, 2017-01-14 14:12 GMT+01:00 B. Blaser : > Hi, > > 2017-01-14 1:42 GMT+01:00 Maurizio Cimadamore : >> >> >> On 13/01/17 21:58, B. Blaser wrote: >>> >>> Hi, >>> >>> 2017-01-13 15:12 GMT+01:00 Maurizio Cimadamore >>> : >>>> >>>> I think that's correct behavior. When you say something like: >>>> >>>> li = get(null); >>> >>> i = get(null); // li = ... is OK ;-) >>> >>>> T will get two constraints: >>>> >>>> * an upper bound (from declared bound) : T <: Iterable >>>> * an upper bound (from return type compatibility) : T <: Integer >>> >>> Integer being final, a correct return type constraint would be >> Integer>, leading to incompatible bounds {T <: Iterable, >> Integer>} and then javac should fail...? >> >> Well, if the spec would ever add some special treatment for finality in >> inference constraints (for instance cast conversion special cases final >> classes to give better results), that woul dbe a way yes - but I'll leave it >> to our spec experts. > In that case, I suggest something like below (line 899 in a more > recent version). > > http://hg.openjdk.java.net/jdk9/dev/langtools/file/b6960e2da008/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#l899 > >> In your examples though, what's really troublesome, is that you have a >> generic method whose type-arguments are only instantiated from the return >> type constraint. When you have a situation like that, and you mix unchecked >> cast, things are going to blow up almost always - final or not. I don't agree with that. Let "Iterable -> List -> ArrayList" be an unique hierarchy. In our example, "li = get()" is meaningful and won't ever fail, but "i = get()" will always blow up! >> I'd be more >> supportive for an optional Lint warning for cases where inference doesn't >> get any constraints from the actual arguments > As unchecked cast produces a warning, javac should probably also emit > at least a warning in our situation; but I'm not sure this would be > really satisfying? Could we express a rule for a "lint" warning (this is not straightforward, I think)? Speaking of rules and inference, I was wondering if it could be imaginable to express facts about known types and bounds with formal logic rules; and then infer type variables using built-in systems like Prolog? > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > @@ -966,9 +966,11 @@ > //if 's' is 'null' there's no instantiated type U for which > //U <: s (but 'null' itself, which is not a valid type) > return false; > + } else if ((s.tsym.flags() & Flags.FINAL) != 0) { > + t.addBound(InferenceBound.EQ, s, Types.this); > + } else { > + t.addBound(InferenceBound.UPPER, s, Types.this); > } > - > - t.addBound(InferenceBound.UPPER, s, Types.this); > return true; > } > > >> - just for a quick comparison, >> C# treats these cases as hard errors; that's not the way Java inference has >> been designed from the start, but that doesn't mean that we couldn't help >> programmers steer away from dubious generic methods (like your 0-ary get() >> method below). I think so, too... >> Maurizio Bernard >>>> The language will then infer T = Integer & Iterable, an >>>> intersection >>>> type. >>>> >>>> Normally this would be fine - but the issue here is that Integer is a >>>> final >>>> class, so that intersection type has no witnesses - e.g. there's no way >>>> for >>>> get() to construct a type that is both an Integer and an Iterable >>>> - >>>> so that will almost always fail - unless get() returns null. >>>> >>>> That said, I'm not aware of any check in the spec for preventing an >>>> intersection type to mention a final class as one of its components so, >>>> while this does look weird, I think the compiler is doing what the >>>> language >>>> spec says. >>>> >>>> Maurizio >>>> >>>> >>>> >>>> On 13/01/17 13:01, B. Blaser wrote: >>>>> >>>>> mport java.util.*; >>>>> >>>>> public class Issue { >>>>> > T get() { return (T)new >>>>> ArrayList(); } >>>>> > T get(T t) { return (T)new >>>>> ArrayList(); } >>>>> >>>>> void run() { >>>>> List li = null; >>>>> LinkedList ll = null; >>>>> Integer i = null; >>>>> >>>>> li = get(null); >>>>> i = get(null); // Shouldn't compile? and will fail at runtime. >>>>> // i = get(li); // Fails as expected >>>>> >>>>> li = get(); >>>>> ll = get(); // OK, but will fail at runtime due to unchecked >>>>> conversion in get(). >>>>> i = get(); // Shouldn't compile? and will fail at runtime. >>>>> } >>>>> >>>>> public static void main(String... args) { >>>>> new Issue().run(); >>>>> } >>>>> } >>>> >>>> >> From forax at univ-mlv.fr Sun Jan 15 11:45:37 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 15 Jan 2017 12:45:37 +0100 (CET) Subject: Incoherent invocation type inference? In-Reply-To: References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> Message-ID: <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> Inference of 0-arity methods in Java is due to the fact that generics were introduced after the collection API in Java, and an explicit goal of the specification of generics was to be able to retrofit classes of java.util. An unsafe warning means that you may get a ClassCastException at runtime. In the collection API, you have methods like Collections.emptyList() that has to return different types depending on the calling context. Calling those methods should not emit a warning because you can not have a CCE at runtime, if you call a method that takes an E will have get an UnsupportedException, if you call a methods that returns an E you will get an IndexOutOfBoundsException or a NoSuchElementException. So you may get a lot of different exceptions but not a CCE, so a call to Collections.emptyList() is safe (with the current definition of what safe means) and the compiler should not trigger any warning. C# is different because if you declare a static field instead of having one static value, you have one static value by type argument, so for C#, it makes sense to force users to specify the type argument given that the returned value will be different. The problem of the code of Bernard is not related to the inference, the problem is the unsafe cast in the implementation, if you use an unsafe cast, then you may have a ClassCastException at runtime. It's as simple as that. regards, R?mi ----- Mail original ----- > De: "B. Blaser" > ?: "Maurizio Cimadamore" > Cc: compiler-dev at openjdk.java.net > Envoy?: Dimanche 15 Janvier 2017 11:34:47 > Objet: Re: Incoherent invocation type inference? > Hi, > > 2017-01-14 14:12 GMT+01:00 B. Blaser : >> Hi, >> >> 2017-01-14 1:42 GMT+01:00 Maurizio Cimadamore : >>> >>> >>> On 13/01/17 21:58, B. Blaser wrote: >>>> >>>> Hi, >>>> >>>> 2017-01-13 15:12 GMT+01:00 Maurizio Cimadamore >>>> : >>>>> >>>>> I think that's correct behavior. When you say something like: >>>>> >>>>> li = get(null); >>>> >>>> i = get(null); // li = ... is OK ;-) >>>> >>>>> T will get two constraints: >>>>> >>>>> * an upper bound (from declared bound) : T <: Iterable >>>>> * an upper bound (from return type compatibility) : T <: Integer >>>> >>>> Integer being final, a correct return type constraint would be >>> Integer>, leading to incompatible bounds {T <: Iterable, >>> Integer>} and then javac should fail...? >>> >>> Well, if the spec would ever add some special treatment for finality in >>> inference constraints (for instance cast conversion special cases final >>> classes to give better results), that woul dbe a way yes - but I'll leave it >>> to our spec experts. >> In that case, I suggest something like below (line 899 in a more >> recent version). >> >> http://hg.openjdk.java.net/jdk9/dev/langtools/file/b6960e2da008/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#l899 >> >>> In your examples though, what's really troublesome, is that you have a >>> generic method whose type-arguments are only instantiated from the return >>> type constraint. When you have a situation like that, and you mix unchecked >>> cast, things are going to blow up almost always - final or not. > > I don't agree with that. Let "Iterable -> List -> ArrayList" be an > unique hierarchy. In our example, "li = get()" is meaningful and won't > ever fail, but "i = get()" will always blow up! > >>> I'd be more >>> supportive for an optional Lint warning for cases where inference doesn't >>> get any constraints from the actual arguments >> As unchecked cast produces a warning, javac should probably also emit >> at least a warning in our situation; but I'm not sure this would be >> really satisfying? > > Could we express a rule for a "lint" warning (this is not > straightforward, I think)? Speaking of rules and inference, I was > wondering if it could be imaginable to express facts about known types > and bounds with formal logic rules; and then infer type variables > using built-in systems like Prolog? > >> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java >> @@ -966,9 +966,11 @@ >> //if 's' is 'null' there's no instantiated type U for which >> //U <: s (but 'null' itself, which is not a valid type) >> return false; >> + } else if ((s.tsym.flags() & Flags.FINAL) != 0) { >> + t.addBound(InferenceBound.EQ, s, Types.this); >> + } else { >> + t.addBound(InferenceBound.UPPER, s, Types.this); >> } >> - >> - t.addBound(InferenceBound.UPPER, s, Types.this); >> return true; >> } >> >> >>> - just for a quick comparison, >>> C# treats these cases as hard errors; that's not the way Java inference has >>> been designed from the start, but that doesn't mean that we couldn't help >>> programmers steer away from dubious generic methods (like your 0-ary get() >>> method below). > > I think so, too... > >>> Maurizio > > Bernard > >>>>> The language will then infer T = Integer & Iterable, an >>>>> intersection >>>>> type. >>>>> >>>>> Normally this would be fine - but the issue here is that Integer is a >>>>> final >>>>> class, so that intersection type has no witnesses - e.g. there's no way >>>>> for >>>>> get() to construct a type that is both an Integer and an Iterable >>>>> - >>>>> so that will almost always fail - unless get() returns null. >>>>> >>>>> That said, I'm not aware of any check in the spec for preventing an >>>>> intersection type to mention a final class as one of its components so, >>>>> while this does look weird, I think the compiler is doing what the >>>>> language >>>>> spec says. >>>>> >>>>> Maurizio >>>>> >>>>> >>>>> >>>>> On 13/01/17 13:01, B. Blaser wrote: >>>>>> >>>>>> mport java.util.*; >>>>>> >>>>>> public class Issue { >>>>>> > T get() { return (T)new >>>>>> ArrayList(); } >>>>>> > T get(T t) { return (T)new >>>>>> ArrayList(); } >>>>>> >>>>>> void run() { >>>>>> List li = null; >>>>>> LinkedList ll = null; >>>>>> Integer i = null; >>>>>> >>>>>> li = get(null); >>>>>> i = get(null); // Shouldn't compile? and will fail at runtime. >>>>>> // i = get(li); // Fails as expected >>>>>> >>>>>> li = get(); >>>>>> ll = get(); // OK, but will fail at runtime due to unchecked >>>>>> conversion in get(). >>>>>> i = get(); // Shouldn't compile? and will fail at runtime. >>>>>> } >>>>>> >>>>>> public static void main(String... args) { >>>>>> new Issue().run(); >>>>>> } >>>>>> } >>>>> >>>>> From istomin.den at gmail.com Sun Jan 15 19:34:16 2017 From: istomin.den at gmail.com (Denis Istomin) Date: Mon, 16 Jan 2017 00:34:16 +0500 Subject: [Patch] 8041793: javap misses newline after printing AnnotationDefault In-Reply-To: <587991F0.8070904@oracle.com> References: <587991F0.8070904@oracle.com> Message-ID: Fixed test: 1. Using getOutputLines instead of getOutput 2. Using toolbox.Assert class with error message instead of throwing simple "Error". -- Denis Istomin 2017-01-14 7:50 GMT+05:00 Jonathan Gibbons : > > > On 01/13/2017 01:38 PM, Denis Istomin wrote: >> >> Hi, >> Made patch for bug 8041793. >> > > Hi Denis, > > The test will probably fail on Windows, because you are checking for the > exact newline character "\n". > > There are two typical solutions to this general problem. > > 1. Take the string returned by the tool and normalize the newlines with code > similar to > out.replace(System.getProperty("line.separator"), "\n") > The system property is also available as a constant within the ToolBox > class. > > 2. Split the output into lines, perhaps by using the getOutputLines method > instead of getOutput, > and then compare the resulting list against an equivalent list for the > expected output. > > Note there are occasions when it is important to verify that the exact > platform line separator sequence > is being used, and that will require different solutions. > > > Your test is also somewhat terse, in that in the case of a problem, it just > says "Error". We run thousands > of tests every day on JDK builds, and when a test fails, it is helpful to > have a test report something more. > In this case, saying "Expected output not found" would be slightly better, > and probably good enough. > In cases where the expected output is bigger, it becomes more helpful to > give more details about where > the mismatch occurs. You don't need to provide a full diff (!), but at least > an indication of the line number > of the first mismatch would help focus the attention of the person who ends > up having to examine why > the test failed. > > -- Jon -------------- next part -------------- # HG changeset patch # User istomin # Date 1484405746 -18000 # Sat Jan 14 19:55:46 2017 +0500 # Branch 8041793-javap-newline # Node ID 1f932aa2b656c660c71b9e45c492606a8753f965 # Parent b6960e2da00806bb8a10c74dfdb73c2dac0f06bc 8041793: javap misses newline after printing AnnotationDefault diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java b/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java --- a/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java @@ -164,6 +164,7 @@ print("default_value: "); annotationWriter.write(attr.default_value); indent(-1); + println(); return null; } diff --git a/test/tools/javap/typeAnnotations/AnnotationDefaultNewlineTest.java b/test/tools/javap/typeAnnotations/AnnotationDefaultNewlineTest.java new file mode 100644 --- /dev/null +++ b/test/tools/javap/typeAnnotations/AnnotationDefaultNewlineTest.java @@ -0,0 +1,71 @@ +/* + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8041793 + * @summary Verify that javap prints newline character after AnnotationDefault value + * @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 toolbox.Assert + * @run main AnnotationDefaultNewlineTest + */ + +import java.util.Collections; +import java.util.List; + +import toolbox.Assert; +import toolbox.JavacTask; +import toolbox.JavapTask; +import toolbox.Task; +import toolbox.ToolBox; + +public class AnnotationDefaultNewlineTest { + + private static final String TestSrc = + "public @interface AnnotationDefault { \n" + + "public abstract int value() default 1; \n" + + "}"; + + private static final String ExpectedSubstring = + " AnnotationDefault:\n" + + " default_value: I#7\n"; + + public static void main(String[] args) throws Exception { + ToolBox tb = new ToolBox(); + new JavacTask(tb).sources(TestSrc).run(); + + List res = new JavapTask(tb) + .options("-v") + .classes("AnnotationDefault.class") + .run() + .getOutputLines(Task.OutputKind.DIRECT); + + List goldenList = tb.split(ExpectedSubstring, "\n"); + Boolean found = Collections.indexOfSubList(res, goldenList) > -1; + + Assert.check(found, "expected output not found: " + ExpectedSubstring); + } +} From istomin.den at gmail.com Sun Jan 15 21:16:12 2017 From: istomin.den at gmail.com (Denis Istomin) Date: Mon, 16 Jan 2017 02:16:12 +0500 Subject: [Patch] 8051768: Inconsistent output for Visible and InvisibleParameterAnnotations In-Reply-To: <58799282.6070905@oracle.com> References: <487145553.1847977.1484291907043.JavaMail.zimbra@u-pem.fr> <58799282.6070905@oracle.com> Message-ID: Fixed newlines and error message. -- Denis Istomin 2017-01-14 7:52 GMT+05:00 Jonathan Gibbons : > > > On 01/13/2017 08:59 AM, Denis Istomin wrote: >> >> Fixed using Void at private method declaration. > > > Denis, > > Same comment as previous review, regarding newlines and terse error > messages. > > -- Jon -------------- next part -------------- # HG changeset patch # User istomin # Date 1484514382 -18000 # Mon Jan 16 02:06:22 2017 +0500 # Branch 8051768-javap-visibleannotation # Node ID 82b1c8d0c91074b4579a1fcccc4d18de1b7a6be5 # Parent b6960e2da00806bb8a10c74dfdb73c2dac0f06bc 8051768: Fix output for Visible and InvisibleParameterAnnotations diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java b/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java --- a/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java @@ -56,6 +56,7 @@ import com.sun.tools.classfile.RuntimeInvisibleAnnotations_attribute; import com.sun.tools.classfile.RuntimeInvisibleParameterAnnotations_attribute; import com.sun.tools.classfile.RuntimeInvisibleTypeAnnotations_attribute; +import com.sun.tools.classfile.RuntimeParameterAnnotations_attribute; import com.sun.tools.classfile.RuntimeVisibleAnnotations_attribute; import com.sun.tools.classfile.RuntimeVisibleParameterAnnotations_attribute; import com.sun.tools.classfile.RuntimeVisibleTypeAnnotations_attribute; @@ -764,9 +765,8 @@ return null; } - @Override - public Void visitRuntimeVisibleParameterAnnotations(RuntimeVisibleParameterAnnotations_attribute attr, Void ignore) { - println("RuntimeVisibleParameterAnnotations:"); + private void visitParameterAnnotations(String message, RuntimeParameterAnnotations_attribute attr) { + println(message); indent(+1); for (int param = 0; param < attr.parameter_annotations.length; param++) { println("parameter " + param + ": "); @@ -779,24 +779,17 @@ indent(-1); } indent(-1); + } + + @Override + public Void visitRuntimeVisibleParameterAnnotations(RuntimeVisibleParameterAnnotations_attribute attr, Void ignore) { + visitParameterAnnotations("RuntimeVisibleParameterAnnotations:", (RuntimeParameterAnnotations_attribute) attr); return null; } @Override public Void visitRuntimeInvisibleParameterAnnotations(RuntimeInvisibleParameterAnnotations_attribute attr, Void ignore) { - println("RuntimeInvisibleParameterAnnotations:"); - indent(+1); - for (int param = 0; param < attr.parameter_annotations.length; param++) { - println(param + ": "); - indent(+1); - for (int i = 0; i < attr.parameter_annotations[param].length; i++) { - print(i + ": "); - annotationWriter.write(attr.parameter_annotations[param][i]); - println(); - } - indent(-1); - } - indent(-1); + visitParameterAnnotations("RuntimeInvisibleParameterAnnotations:", (RuntimeParameterAnnotations_attribute) attr); return null; } diff --git a/test/tools/javap/typeAnnotations/InvisibleParameterAnnotationsTest.java b/test/tools/javap/typeAnnotations/InvisibleParameterAnnotationsTest.java new file mode 100644 --- /dev/null +++ b/test/tools/javap/typeAnnotations/InvisibleParameterAnnotationsTest.java @@ -0,0 +1,87 @@ +/* + * Copyright (c) 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8051768 + * @summary Verify that javap prints "param" for RuntimeInvisibleParameterAnnotations + * @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 toolbox.Assert + * @run main InvisibleParameterAnnotationsTest + */ + +import toolbox.Assert; +import toolbox.JavacTask; +import toolbox.JavapTask; +import toolbox.Task; +import toolbox.ToolBox; + +import java.util.Collections; +import java.util.List; + +public class InvisibleParameterAnnotationsTest { + + private static final String TestSrc = + "import java.lang.annotation.Retention \n;" + + "import java.lang.annotation.RetentionPolicy \n;" + + + "public class Sample { \n" + + + "@Retention(RetentionPolicy.CLASS) \n" + + "public @interface InvisAnno{} \n" + + "@Retention(RetentionPolicy.RUNTIME) \n" + + "public @interface VisAnno{} \n" + + + "public void Method(@InvisAnno int arg1, at VisAnno int arg2){};" + + "}"; + + private static final String ExpectedSubstring = + " RuntimeVisibleParameterAnnotations:\n" + + " parameter 0:\n" + + " parameter 1:\n" + + " 0: #16()\n" + + " RuntimeInvisibleParameterAnnotations:\n" + + " parameter 0:\n" + + " 0: #18()\n" + + " parameter 1:"; + + public static void main(String[] args) throws Exception { + ToolBox tb = new ToolBox(); + new JavacTask(tb).sources(TestSrc).run(); + + List res = new JavapTask(tb) + .options("-v") + .classes("Sample.class") + .run() + .getOutputLines(Task.OutputKind.DIRECT); + + List expectedList = tb.split(ExpectedSubstring, "\n"); + Boolean found = Collections.indexOfSubList(res, expectedList) > -1; + Assert.check(found, "expected output not found: " + ExpectedSubstring); + } +} From maurizio.cimadamore at oracle.com Sun Jan 15 21:44:15 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Sun, 15 Jan 2017 21:44:15 +0000 Subject: Incoherent invocation type inference? In-Reply-To: <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> Message-ID: <43f3f78e-73ef-e54d-91dc-47f2b56b2e8b@oracle.com> > The problem of the code of Bernard is not related to the inference, the problem is the unsafe cast in the implementation, if you use an unsafe cast, then you may have a ClassCastException at runtime. It's as simple as that. Of course that's the problem :-) I was speculating as to whether there could be something the compiler could do to help out programmers setting right expectations for a given generic method signature, as I've seen this problem (unchecked issues mistaken for inference issues) coming up frequently. Maurizio From bsrbnd at gmail.com Mon Jan 16 11:37:08 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 16 Jan 2017 12:37:08 +0100 Subject: Incoherent invocation type inference? In-Reply-To: <43f3f78e-73ef-e54d-91dc-47f2b56b2e8b@oracle.com> References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> <43f3f78e-73ef-e54d-91dc-47f2b56b2e8b@oracle.com> Message-ID: Hi, 2017-01-15 22:44 GMT+01:00 Maurizio Cimadamore : > >> The problem of the code of Bernard is not related to the inference, the >> problem is the unsafe cast in the implementation, if you use an unsafe cast, >> then you may have a ClassCastException at runtime. It's as simple as that. > > Of course that's the problem :-) > > I was speculating as to whether there could be something the compiler could > do to help out programmers setting right expectations for a given generic > method signature, as I've seen this problem (unchecked issues mistaken for > inference issues) coming up frequently. > > Maurizio The problem I see in our example is that: - if we had a method "Iterable get()", "i=get()" won't be possible unless an existing "class C extends Integer implements Iterable" exists; and in such a case we had to cast explicitly "i=(C)get()". - but with " T get()", javac infers T to an hypothetical intersection type without knowing if such a type exists or could even exist (no, in the case of a final class). So, I suggest a general "lint" warning if javac infers T to an intersection type, because T is widened without being sure that it is possible; this would be cohernent with the "lint" warning for the unchecked cast "(T)" in "get()". What do you think of such a rule? Thanks, Bernard From maurizio.cimadamore at oracle.com Mon Jan 16 12:51:26 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 16 Jan 2017 12:51:26 +0000 Subject: Incoherent invocation type inference? In-Reply-To: References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> <43f3f78e-73ef-e54d-91dc-47f2b56b2e8b@oracle.com> Message-ID: On 16/01/17 11:37, B. Blaser wrote: > So, I suggest a general "lint" warning if javac infers T to an > intersection type, because T is widened without being sure that it is > possible; this would be cohernent with the "lint" warning for the > unchecked cast "(T)" in "get()". I don't think you want that - there are cases where javac infers an intersection type which are totally legitimate: interface I { } class S { } class A extends S implements I { } class B extends S implements I { } class Test { Z choose(Z z1, Z z2, boolean cond) { return cond ? z1 : z2; } void test() { choose(new A(), new B(), false); } } I don't think intersection types are the evil in your example. Even leaving intersection types aside: class Issue { T get() { return (T)new ArrayList(); } void run() { LinkedList ll = null; ll = get(); // OK, but will fail at runtime due to unchecked conversion in get(). } public static void main(String... args) { new Issue().run(); } } So, I guess I'm not exactly sure of what we're trying to improve here? Maurizio From maurizio.cimadamore at oracle.com Mon Jan 16 15:25:11 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 16 Jan 2017 15:25:11 +0000 Subject: Incoherent invocation type inference? In-Reply-To: References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> <43f3f78e-73ef-e54d-91dc-47f2b56b2e8b@oracle.com> Message-ID: <7d0167b4-6085-9256-7073-61e9bf9ddfdb@oracle.com> On 16/01/17 12:51, Maurizio Cimadamore wrote: > I don't think intersection types are the evil in your example. Even > leaving intersection types aside: > > class Issue { > T get() { return (T)new ArrayList(); } > > void run() { > LinkedList ll = null; > ll = get(); // OK, but will fail at runtime due to unchecked > conversion in get(). > } > > public static void main(String... args) { > new Issue().run(); > } > } > > So, I guess I'm not exactly sure of what we're trying to improve here? To clarify - what I'm saying here is: the main issue is that get() is promising that ArrayList will be compatible with T. This promise is unsound - as T is basically controlled by client code, so it can be fixed to whatever type the client wants. That's the condition that smells, IMHO. It's true that, as Remi pointed out, there are cases where unchecked conversion and return type inference play well together - as in Collections.emptyList - but there's a big difference in that method: public static final List emptyList() The return type here is not a naked type-variable T - but List. So, while the client can control the parameterization (List vs List) it *cannot* control the base type (List vs String). The combination of unchecked return assignment and a naked generic method type-variable return are IMHO always a source of smell in generic code - that's what I was referring to with the Lint digression. As far as intersection types are concerned - I sense that it's easier to add new well-formedness rules about such types rather than changing the way in which inference constraints are set up based on finality of a class. Having such checks would also prevent users from spelling bad intersection types in their code (e.g. a cast with an intersection type target - which is possible since Java SE 8). Maurizio From bsrbnd at gmail.com Mon Jan 16 16:49:50 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 16 Jan 2017 17:49:50 +0100 Subject: Incoherent invocation type inference? In-Reply-To: <7d0167b4-6085-9256-7073-61e9bf9ddfdb@oracle.com> References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> <43f3f78e-73ef-e54d-91dc-47f2b56b2e8b@oracle.com> <7d0167b4-6085-9256-7073-61e9bf9ddfdb@oracle.com> Message-ID: 2017-01-16 16:25 GMT+01:00 Maurizio Cimadamore : > > > On 16/01/17 12:51, Maurizio Cimadamore wrote: >> >> I don't think intersection types are the evil in your example. Even >> leaving intersection types aside: >> >> class Issue { >> T get() { return (T)new ArrayList(); } >> >> void run() { >> LinkedList ll = null; >> ll = get(); // OK, but will fail at runtime due to unchecked >> conversion in get(). >> } >> >> public static void main(String... args) { >> new Issue().run(); >> } >> } >> >> So, I guess I'm not exactly sure of what we're trying to improve here? > > To clarify - what I'm saying here is: the main issue is that get() is > promising that ArrayList will be compatible with T. This promise is > unsound - as T is basically controlled by client code, so it can be fixed to > whatever type the client wants. That's the condition that smells, IMHO. > > It's true that, as Remi pointed out, there are cases where unchecked > conversion and return type inference play well together - as in > Collections.emptyList - but there's a big difference in that method: > > public static final List emptyList() > > The return type here is not a naked type-variable T - but List. So, while > the client can control the parameterization (List vs List) > it *cannot* control the base type (List vs String). > > The combination of unchecked return assignment and a naked generic method > type-variable return are IMHO always a source of smell in generic code - > that's what I was referring to with the Lint digression. > > As far as intersection types are concerned - I sense that it's easier to add > new well-formedness rules about such types rather than changing the way in > which inference constraints are set up based on finality of a class. Having > such checks would also prevent users from spelling bad intersection types in > their code (e.g. a cast with an intersection type target - which is possible > since Java SE 8). > > Maurizio Intersections seem to be dangerous only in the case of a naked return type variable with no parameter provided ("get()" or "get(null)") because get() wouldn't know about the return type constraints. We could, for example, update the rule as follows: "emit a lint warning if the return type T is a naked type variable infered to an intersection type and no constraint is given by the actual arguments"? Or are you suggesting to modify the rules of intersection types on the language side? Bernard From maurizio.cimadamore at oracle.com Mon Jan 16 17:03:28 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 16 Jan 2017 17:03:28 +0000 Subject: Incoherent invocation type inference? In-Reply-To: References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> <43f3f78e-73ef-e54d-91dc-47f2b56b2e8b@oracle.com> <7d0167b4-6085-9256-7073-61e9bf9ddfdb@oracle.com> Message-ID: <42944d98-ef8d-5f29-32aa-cac5581f96f5@oracle.com> On 16/01/17 16:49, B. Blaser wrote: > 2017-01-16 16:25 GMT+01:00 Maurizio Cimadamore : >> >> On 16/01/17 12:51, Maurizio Cimadamore wrote: >>> I don't think intersection types are the evil in your example. Even >>> leaving intersection types aside: >>> >>> class Issue { >>> T get() { return (T)new ArrayList(); } >>> >>> void run() { >>> LinkedList ll = null; >>> ll = get(); // OK, but will fail at runtime due to unchecked >>> conversion in get(). >>> } >>> >>> public static void main(String... args) { >>> new Issue().run(); >>> } >>> } >>> >>> So, I guess I'm not exactly sure of what we're trying to improve here? >> To clarify - what I'm saying here is: the main issue is that get() is >> promising that ArrayList will be compatible with T. This promise is >> unsound - as T is basically controlled by client code, so it can be fixed to >> whatever type the client wants. That's the condition that smells, IMHO. >> >> It's true that, as Remi pointed out, there are cases where unchecked >> conversion and return type inference play well together - as in >> Collections.emptyList - but there's a big difference in that method: >> >> public static final List emptyList() >> >> The return type here is not a naked type-variable T - but List. So, while >> the client can control the parameterization (List vs List) >> it *cannot* control the base type (List vs String). >> >> The combination of unchecked return assignment and a naked generic method >> type-variable return are IMHO always a source of smell in generic code - >> that's what I was referring to with the Lint digression. >> >> As far as intersection types are concerned - I sense that it's easier to add >> new well-formedness rules about such types rather than changing the way in >> which inference constraints are set up based on finality of a class. Having >> such checks would also prevent users from spelling bad intersection types in >> their code (e.g. a cast with an intersection type target - which is possible >> since Java SE 8). >> >> Maurizio > Intersections seem to be dangerous only in the case of a naked return > type variable with no parameter provided ("get()" or "get(null)") > because get() wouldn't know about the return type constraints. We > could, for example, update the rule as follows: "emit a lint warning > if the return type T is a naked type variable infered to an > intersection type and no constraint is given by the actual arguments"? > > Or are you suggesting to modify the rules of intersection types on the > language side? I think the Lint warning makes sense for naked return type regardless of intersections - as in the example I wrote. Then, for tightening intersections, we could add more rules on the language side. Note that javac already prevents you from creating an intersection out of List and List (different param of the same generic interface), so perhaps something about 'final' should be added to (either as an official, specified check, or just as a Lint one). Maurizio > > Bernard From bsrbnd at gmail.com Mon Jan 16 18:33:09 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 16 Jan 2017 19:33:09 +0100 Subject: Incoherent invocation type inference? In-Reply-To: <42944d98-ef8d-5f29-32aa-cac5581f96f5@oracle.com> References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> <43f3f78e-73ef-e54d-91dc-47f2b56b2e8b@oracle.com> <7d0167b4-6085-9256-7073-61e9bf9ddfdb@oracle.com> <42944d98-ef8d-5f29-32aa-cac5581f96f5@oracle.com> Message-ID: 2017-01-16 18:03 GMT+01:00 Maurizio Cimadamore : > > > On 16/01/17 16:49, B. Blaser wrote: >> >> 2017-01-16 16:25 GMT+01:00 Maurizio Cimadamore >> : >>> >>> >>> On 16/01/17 12:51, Maurizio Cimadamore wrote: >>>> >>>> I don't think intersection types are the evil in your example. Even >>>> leaving intersection types aside: >>>> >>>> class Issue { >>>> T get() { return (T)new ArrayList(); } >>>> >>>> void run() { >>>> LinkedList ll = null; >>>> ll = get(); // OK, but will fail at runtime due to unchecked >>>> conversion in get(). >>>> } >>>> >>>> public static void main(String... args) { >>>> new Issue().run(); >>>> } >>>> } >>>> >>>> So, I guess I'm not exactly sure of what we're trying to improve here? >>> >>> To clarify - what I'm saying here is: the main issue is that get() is >>> promising that ArrayList will be compatible with T. This promise >>> is >>> unsound - as T is basically controlled by client code, so it can be fixed >>> to >>> whatever type the client wants. That's the condition that smells, IMHO. >>> >>> It's true that, as Remi pointed out, there are cases where unchecked >>> conversion and return type inference play well together - as in >>> Collections.emptyList - but there's a big difference in that method: >>> >>> public static final List emptyList() >>> >>> The return type here is not a naked type-variable T - but List. So, >>> while >>> the client can control the parameterization (List vs >>> List) >>> it *cannot* control the base type (List vs String). >>> >>> The combination of unchecked return assignment and a naked generic method >>> type-variable return are IMHO always a source of smell in generic code - >>> that's what I was referring to with the Lint digression. >>> >>> As far as intersection types are concerned - I sense that it's easier to >>> add >>> new well-formedness rules about such types rather than changing the way >>> in >>> which inference constraints are set up based on finality of a class. >>> Having >>> such checks would also prevent users from spelling bad intersection types >>> in >>> their code (e.g. a cast with an intersection type target - which is >>> possible >>> since Java SE 8). >>> >>> Maurizio >> >> Intersections seem to be dangerous only in the case of a naked return >> type variable with no parameter provided ("get()" or "get(null)") >> because get() wouldn't know about the return type constraints. We >> could, for example, update the rule as follows: "emit a lint warning >> if the return type T is a naked type variable infered to an >> intersection type and no constraint is given by the actual arguments"? >> >> Or are you suggesting to modify the rules of intersection types on the >> language side? > > I think the Lint warning makes sense for naked return type regardless of > intersections - as in the example I wrote. Ok for this first rule. > Then, for tightening intersections, we could add more rules on the language > side. Note that javac already prevents you from creating an intersection out > of List and List (different param of the same generic > interface), so perhaps something about 'final' should be added to (either as > an official, specified check, or just as a Lint one). For the final class, I would be tempted to say that the equality constraint is "obvious"; but if it isn't compliant with the language specification, we could explore a Lint warning too... Bernard > Maurizio From bsrbnd at gmail.com Wed Jan 18 12:50:00 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 18 Jan 2017 13:50:00 +0100 Subject: Incoherent invocation type inference? In-Reply-To: References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> <43f3f78e-73ef-e54d-91dc-47f2b56b2e8b@oracle.com> <7d0167b4-6085-9256-7073-61e9bf9ddfdb@oracle.com> <42944d98-ef8d-5f29-32aa-cac5581f96f5@oracle.com> Message-ID: Hi, 2017-01-16 19:33 GMT+01:00 B. Blaser : > 2017-01-16 18:03 GMT+01:00 Maurizio Cimadamore : >> >> On 16/01/17 16:49, B. Blaser wrote: >>> >>> Intersections seem to be dangerous only in the case of a naked return >>> type variable with no parameter provided ("get()" or "get(null)") >>> because get() wouldn't know about the return type constraints. We >>> could, for example, update the rule as follows: "emit a lint warning >>> if the return type T is a naked type variable infered to an >>> intersection type and no constraint is given by the actual arguments"? >>> >>> Or are you suggesting to modify the rules of intersection types on the >>> language side? >> >> I think the Lint warning makes sense for naked return type regardless of >> intersections - as in the example I wrote. > > Ok for this first rule. What do you think of something like the draft below (Infer.instantiateMethod() upon rev. b6960e2da008)? Thanks, Bernard >> Maurizio diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java @@ -182,6 +182,26 @@ final InferenceContext inferenceContext = new InferenceContext(this, tvars); //B0 inferenceException.clear(); try { + if (resultInfo != null && resultInfo.pt != Type.noType && mt.restype.hasTag(TYPEVAR)) { + int nbConstraints = 0; + if (mt.argtypes.length() == argtypes.length()) { + for (int i=0; i References: <4E1C251C-163A-4093-855F-CEDC043B8524@pivotal.io> Message-ID: Hi again, didn't get much response but it looks like there are some improvements for lambdas planned for at least JDK10 [0]. Is what I asked for below maybe a candidate for inclusion into those efforts? Is there maybe a better place to ask for this? Cheers, Ollie [0] https://www.infoq.com/news/2017/01/java10-lambda-leftovers > Am 23.12.2016 um 12:22 schrieb Oliver Gierke : > > Hi all, > > Lambda based implementations of SAM types currently don't support inspecting the type for generic type parameters. This can cause unexpected surprise as some high-level API taking a SAM type as parameter is usually an indicator to users, that they can be used with Lambdas. If the object passed in is then inspected for generic types somewhere down the call stack this causes issues. Handing in a dedicated implementation of the SAM type is a workaround bit I think that's highly confusing and can be a source of errors hard to understand and debug. > > I've added an example below. > > Cheers, > Ollie > > public class LambdaTypeDetectionSample { > > public static void main(String[] args) { > > Function lambdaFunction = i -> i.toString(); > Function oldschoolFunction = new Function() { > > public String apply(Integer t) { > return t.toString(); > } > }; > > printTypeArguments(oldschoolFunction); > > // Yields: > // java.util.function.Function is a class sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl > // class java.lang.Integer > // class java.lang.String > > printTypeArguments(lambdaFunction); > > // Yields: > // interface java.util.function.Function is a class java.lang.Class > } > > private static void printTypeArguments(Function function) { > > Type type = function.getClass().getGenericInterfaces()[0]; > > System.out.println(type + " is a " + type.getClass()); > > if (type instanceof ParameterizedType) { > > ParameterizedType functionInterface = (ParameterizedType) type; > Arrays.stream(functionInterface.getActualTypeArguments()).forEach(System.out::println); > } > } > } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From forax at univ-mlv.fr Wed Jan 18 19:02:00 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 18 Jan 2017 20:02:00 +0100 (CET) Subject: Issues with generic type detection of SAM types implemented using lambdas In-Reply-To: References: <4E1C251C-163A-4093-855F-CEDC043B8524@pivotal.io> Message-ID: <896018888.1480743.1484766120051.JavaMail.zimbra@u-pem.fr> Hi Oliver, sorry for not responding earlier, not having the generic type information was something discussed by the lambda export group, and i'm sure you can also find several threads about that subject on lambda-dev. There are two reasons to not generate the generic info at runtime: - these info are used to enable separate compilation, because of the erasure, the argument of the parameterized types is lost, so at the method boundary, the compiler has to keep the generic information to enable separate compilation. At runtime, when the class that hosts a lambda is generated, there is no need for such information. - a lambda at runtime should be as lightweight as possible (at least for non serializable lambdas), so the spec allows to have several lambdas that share the same class at runtime, in that context having one generic information for several lambdas make no sense. regards, R?mi ----- Mail original ----- > De: "Oliver Gierke" > ?: compiler-dev at openjdk.java.net > Envoy?: Mercredi 18 Janvier 2017 19:06:30 > Objet: Re: Issues with generic type detection of SAM types implemented using lambdas > Hi again, > > didn't get much response but it looks like there are some improvements for > lambdas planned for at least JDK10 [0]. Is what I asked for below maybe a > candidate for inclusion into those efforts? > > Is there maybe a better place to ask for this? > > Cheers, > Ollie > > [0] https://www.infoq.com/news/2017/01/java10-lambda-leftovers > >> Am 23.12.2016 um 12:22 schrieb Oliver Gierke : >> >> Hi all, >> >> Lambda based implementations of SAM types currently don't support inspecting the >> type for generic type parameters. This can cause unexpected surprise as some >> high-level API taking a SAM type as parameter is usually an indicator to users, >> that they can be used with Lambdas. If the object passed in is then inspected >> for generic types somewhere down the call stack this causes issues. Handing in >> a dedicated implementation of the SAM type is a workaround bit I think that's >> highly confusing and can be a source of errors hard to understand and debug. >> >> I've added an example below. >> >> Cheers, >> Ollie >> >> public class LambdaTypeDetectionSample { >> >> public static void main(String[] args) { >> >> Function lambdaFunction = i -> i.toString(); >> Function oldschoolFunction = new Function() { >> >> public String apply(Integer t) { >> return t.toString(); >> } >> }; >> >> printTypeArguments(oldschoolFunction); >> >> // Yields: >> // java.util.function.Function is a class >> sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl >> // class java.lang.Integer >> // class java.lang.String >> >> printTypeArguments(lambdaFunction); >> >> // Yields: >> // interface java.util.function.Function is a class java.lang.Class >> } >> >> private static void printTypeArguments(Function function) { >> >> Type type = function.getClass().getGenericInterfaces()[0]; >> >> System.out.println(type + " is a " + type.getClass()); >> >> if (type instanceof ParameterizedType) { >> >> ParameterizedType functionInterface = (ParameterizedType) type; >> Arrays.stream(functionInterface.getActualTypeArguments()).forEach(System.out::println); >> } >> } > > } From joe.darcy at oracle.com Wed Jan 18 22:45:17 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 18 Jan 2017 14:45:17 -0800 Subject: JDK 9 RFR of JDK-8172910: Use default methods as appropriate for language model visitors Message-ID: Hello, When visitModule as added to ElementVisitor (JDK-8142968), it was added as a normal abstract interface method. This approach was necessary in analogous cases back in Java SE 8 since the package in question is built under the previously JDK during the bootstrap process. For 9, better source compatibility would come from using a default method here. Please review the webrev which implements this improvement: 8172910: Use default methods as appropriate for language model visitors http://cr.openjdk.java.net/~darcy/8172910.1/ Likewise, several convenience methods in the visitor interfaces can be upgraded to default methods as a small convenience for those directly implementing the interfaces. Thanks, -Joe From jonathan.gibbons at oracle.com Wed Jan 18 22:53:02 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 18 Jan 2017 14:53:02 -0800 Subject: JDK 9 RFR of JDK-8172910: Use default methods as appropriate for language model visitors In-Reply-To: References: Message-ID: <587FF1CE.7090601@oracle.com> Joe, Your webrev appears to be broken; the wdiffs are all empty files. For example, see this listing: ee http://cr.openjdk.java.net/~darcy/8172910.1/src/java.compiler/share/classes/javax/lang/model/element/ -- Jon On 01/18/2017 02:45 PM, joe darcy wrote: > Hello, > > When visitModule as added to ElementVisitor (JDK-8142968), it was > added as a normal abstract interface method. This approach was > necessary in analogous cases back in Java SE 8 since the package in > question is built under the previously JDK during the bootstrap > process. For 9, better source compatibility would come from using a > default method here. > > Please review the webrev which implements this improvement: > > 8172910: Use default methods as appropriate for language model > visitors > http://cr.openjdk.java.net/~darcy/8172910.1/ > > Likewise, several convenience methods in the visitor interfaces can be > upgraded to default methods as a small convenience for those directly > implementing the interfaces. > > Thanks, > > -Joe > From joe.darcy at oracle.com Wed Jan 18 22:59:00 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 18 Jan 2017 14:59:00 -0800 Subject: JDK 9 RFR of JDK-8172910: Use default methods as appropriate for language model visitors In-Reply-To: <587FF1CE.7090601@oracle.com> References: <587FF1CE.7090601@oracle.com> Message-ID: <2c097a76-bd4c-102f-2feb-e06cb96b5215@oracle.com> Hi Jon, Hmm; strange. I'll look into the wdiff problem; all the other kinds of diffs seem to be functional though. Thanks, -Joe On 1/18/2017 2:53 PM, Jonathan Gibbons wrote: > Joe, > > Your webrev appears to be broken; the wdiffs are all empty files. > > For example, see this listing: ee > http://cr.openjdk.java.net/~darcy/8172910.1/src/java.compiler/share/classes/javax/lang/model/element/ > > -- Jon > > > > On 01/18/2017 02:45 PM, joe darcy wrote: >> Hello, >> >> When visitModule as added to ElementVisitor (JDK-8142968), it was >> added as a normal abstract interface method. This approach was >> necessary in analogous cases back in Java SE 8 since the package in >> question is built under the previously JDK during the bootstrap >> process. For 9, better source compatibility would come from using a >> default method here. >> >> Please review the webrev which implements this improvement: >> >> 8172910: Use default methods as appropriate for language model >> visitors >> http://cr.openjdk.java.net/~darcy/8172910.1/ >> >> Likewise, several convenience methods in the visitor interfaces can >> be upgraded to default methods as a small convenience for those >> directly implementing the interfaces. >> >> Thanks, >> >> -Joe >> > From jonathan.gibbons at oracle.com Wed Jan 18 23:00:49 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 18 Jan 2017 15:00:49 -0800 Subject: JDK 9 RFR of JDK-8172910: Use default methods as appropriate for language model visitors In-Reply-To: <2c097a76-bd4c-102f-2feb-e06cb96b5215@oracle.com> References: <587FF1CE.7090601@oracle.com> <2c097a76-bd4c-102f-2feb-e06cb96b5215@oracle.com> Message-ID: <587FF3A1.8020002@oracle.com> Yeah, I can review the other formats -- Jon On 01/18/2017 02:59 PM, joe darcy wrote: > Hi Jon, > > Hmm; strange. I'll look into the wdiff problem; all the other kinds of > diffs seem to be functional though. > > Thanks, > > -Joe > > > On 1/18/2017 2:53 PM, Jonathan Gibbons wrote: >> Joe, >> >> Your webrev appears to be broken; the wdiffs are all empty files. >> >> For example, see this listing: ee >> http://cr.openjdk.java.net/~darcy/8172910.1/src/java.compiler/share/classes/javax/lang/model/element/ >> >> -- Jon >> >> >> >> On 01/18/2017 02:45 PM, joe darcy wrote: >>> Hello, >>> >>> When visitModule as added to ElementVisitor (JDK-8142968), it was >>> added as a normal abstract interface method. This approach was >>> necessary in analogous cases back in Java SE 8 since the package in >>> question is built under the previously JDK during the bootstrap >>> process. For 9, better source compatibility would come from using a >>> default method here. >>> >>> Please review the webrev which implements this improvement: >>> >>> 8172910: Use default methods as appropriate for language model >>> visitors >>> http://cr.openjdk.java.net/~darcy/8172910.1/ >>> >>> Likewise, several convenience methods in the visitor interfaces can >>> be upgraded to default methods as a small convenience for those >>> directly implementing the interfaces. >>> >>> Thanks, >>> >>> -Joe >>> >> > From jonathan.gibbons at oracle.com Wed Jan 18 23:19:38 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 18 Jan 2017 15:19:38 -0800 Subject: JDK 9 RFR of JDK-8172910: Use default methods as appropriate for language model visitors In-Reply-To: References: Message-ID: <587FF80A.6010705@oracle.com> Looks OK to me. -- Jon On 01/18/2017 02:45 PM, joe darcy wrote: > Hello, > > When visitModule as added to ElementVisitor (JDK-8142968), it was > added as a normal abstract interface method. This approach was > necessary in analogous cases back in Java SE 8 since the package in > question is built under the previously JDK during the bootstrap > process. For 9, better source compatibility would come from using a > default method here. > > Please review the webrev which implements this improvement: > > 8172910: Use default methods as appropriate for language model > visitors > http://cr.openjdk.java.net/~darcy/8172910.1/ > > Likewise, several convenience methods in the visitor interfaces can be > upgraded to default methods as a small convenience for those directly > implementing the interfaces. > > Thanks, > > -Joe > From maurizio.cimadamore at oracle.com Thu Jan 19 01:52:38 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 19 Jan 2017 01:52:38 +0000 Subject: Issues with generic type detection of SAM types implemented using lambdas In-Reply-To: References: <4E1C251C-163A-4093-855F-CEDC043B8524@pivotal.io> Message-ID: Hi Oliver, this request seems to be similar to other requests expressed in the past: Signature attribute on lambda method: http://mail.openjdk.java.net/pipermail/compiler-dev/2015-January/009220.html Annotations on lambdas: http://mail.openjdk.java.net/pipermail/compiler-dev/2015-July/009662.html The recurring theme is that we don't want to make promises on implementation details - that is how is a lambda implemented. For now, a lambda is implemented as a (dynamically generated) anonymous class instance - so certain requests seem to make sense. But as the implementation will get better at sharing, having to expose details such as signature attributes and such will become an obstacle to further improvements. For instance, the runtime does NOT have to distinguish between a Supplier and a Supplier - example: class Test { void test() { Supplier ss = this::m; Supplier si = this::m; } String m() { return ""; } } This gives the following bytceode: void test(); descriptor: ()V flags: Code: stack=1, locals=3, args_size=1 0: aload_0 1: invokedynamic #2, 0 // InvokeDynamic #0:get:(LTest;)Ljava/util/function/Supplier; 6: astore_1 7: aload_0 8: invokedynamic #3, 0 // InvokeDynamic #1:get:(LTest;)Ljava/util/function/Supplier; 13: astore_2 14: return BootstrapMethods: 0: #18 invokestatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; Method arguments: #19 ()Ljava/lang/Object; #20 invokevirtual Test.m:()Ljava/lang/String; #21 ()Ljava/lang/String; 1: #18 invokestatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; Method arguments: #19 ()Ljava/lang/Object; #20 invokevirtual Test.m:()Ljava/lang/String; #19 ()Ljava/lang/Object; As you can see, both invokedynamic share the same SAM type - the erased java/util/function/Supplier. The only difference between the two indys is the method type passed as 3rd static argument - in one case ()String is passed, in the other ()Object is passed - that dictates the signature of the dynamically generated method implementing the sam type. In other words, if the lambda metafactory used the same instance for both method references, everything would still work (in fact, the generated bytecode is the same for both classes!). Maurizio On 18/01/17 18:06, Oliver Gierke wrote: > Hi again, > > didn't get much response but it looks like there are some improvements for lambdas planned for at least JDK10 [0]. Is what I asked for below maybe a candidate for inclusion into those efforts? > > Is there maybe a better place to ask for this? > > Cheers, > Ollie > > [0] https://www.infoq.com/news/2017/01/java10-lambda-leftovers > >> Am 23.12.2016 um 12:22 schrieb Oliver Gierke : >> >> Hi all, >> >> Lambda based implementations of SAM types currently don't support inspecting the type for generic type parameters. This can cause unexpected surprise as some high-level API taking a SAM type as parameter is usually an indicator to users, that they can be used with Lambdas. If the object passed in is then inspected for generic types somewhere down the call stack this causes issues. Handing in a dedicated implementation of the SAM type is a workaround bit I think that's highly confusing and can be a source of errors hard to understand and debug. >> >> I've added an example below. >> >> Cheers, >> Ollie >> >> public class LambdaTypeDetectionSample { >> >> public static void main(String[] args) { >> >> Function lambdaFunction = i -> i.toString(); >> Function oldschoolFunction = new Function() { >> >> public String apply(Integer t) { >> return t.toString(); >> } >> }; >> >> printTypeArguments(oldschoolFunction); >> >> // Yields: >> // java.util.function.Function is a class sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl >> // class java.lang.Integer >> // class java.lang.String >> >> printTypeArguments(lambdaFunction); >> >> // Yields: >> // interface java.util.function.Function is a class java.lang.Class >> } >> >> private static void printTypeArguments(Function function) { >> >> Type type = function.getClass().getGenericInterfaces()[0]; >> >> System.out.println(type + " is a " + type.getClass()); >> >> if (type instanceof ParameterizedType) { >> >> ParameterizedType functionInterface = (ParameterizedType) type; >> Arrays.stream(functionInterface.getActualTypeArguments()).forEach(System.out::println); >> } >> } >> } From ogierke at pivotal.io Thu Jan 19 07:40:26 2017 From: ogierke at pivotal.io (Oliver Gierke) Date: Thu, 19 Jan 2017 08:40:26 +0100 Subject: Issues with generic type detection of SAM types implemented using lambdas In-Reply-To: References: <4E1C251C-163A-4093-855F-CEDC043B8524@pivotal.io> Message-ID: <63C94B5C-4E18-4500-9203-15408B98D5EA@pivotal.io> Hi Maurizio, thanks again for you in-depth explanation. I get all that and the design considerations behind the decisions that were made. I just wanted to point out that an ordinary user -- in general client code that uses APIs with SAM types -- *has to implicitly know* whether *any code* (potentially Java 6 based) downstream might attempt generics resolution before she can decide whether to use a Lambda with this SAM type. I think that's a very fundamental usability problem because it doesn't even need some arbitrary corner case. If there's a piece of code attempting the resolution anywhere downstream, it just won't work. Never. The only similar scenario (in terms of some parts of the reflection API not working as others) I remember is debug symbols on interface methods. That was changed in Java 8 with the -parameters flag. So I thought, it might be worth bringing this one up here as maybe the context has or will have changed for Java 9 / 10. Cheers, Ollie > Am 19.01.2017 um 02:52 schrieb Maurizio Cimadamore : > > Hi Oliver, > this request seems to be similar to other requests expressed in the past: > > Signature attribute on lambda method: > > http://mail.openjdk.java.net/pipermail/compiler-dev/2015-January/009220.html > > Annotations on lambdas: > > http://mail.openjdk.java.net/pipermail/compiler-dev/2015-July/009662.html > > > The recurring theme is that we don't want to make promises on implementation details - that is how is a lambda implemented. For now, a lambda is implemented as a (dynamically generated) anonymous class instance - so certain requests seem to make sense. But as the implementation will get better at sharing, having to expose details such as signature attributes and such will become an obstacle to further improvements. > > For instance, the runtime does NOT have to distinguish between a Supplier and a Supplier - example: > > class Test { > void test() { > Supplier ss = this::m; > Supplier si = this::m; > } > > String m() { return ""; } > } > > This gives the following bytceode: > > void test(); > descriptor: ()V > flags: > Code: > stack=1, locals=3, args_size=1 > 0: aload_0 > 1: invokedynamic #2, 0 // InvokeDynamic #0:get:(LTest;)Ljava/util/function/Supplier; > 6: astore_1 > 7: aload_0 > 8: invokedynamic #3, 0 // InvokeDynamic #1:get:(LTest;)Ljava/util/function/Supplier; > 13: astore_2 > 14: return > > BootstrapMethods: > 0: #18 invokestatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > Method arguments: > #19 ()Ljava/lang/Object; > #20 invokevirtual Test.m:()Ljava/lang/String; > #21 ()Ljava/lang/String; > 1: #18 invokestatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite; > Method arguments: > #19 ()Ljava/lang/Object; > #20 invokevirtual Test.m:()Ljava/lang/String; > #19 ()Ljava/lang/Object; > > > As you can see, both invokedynamic share the same SAM type - the erased java/util/function/Supplier. The only difference between the two indys is the method type passed as 3rd static argument - in one case ()String is passed, in the other ()Object is passed - that dictates the signature of the dynamically generated method implementing the sam type. > > In other words, if the lambda metafactory used the same instance for both method references, everything would still work (in fact, the generated bytecode is the same for both classes!). > > Maurizio > > > > On 18/01/17 18:06, Oliver Gierke wrote: >> Hi again, >> >> didn't get much response but it looks like there are some improvements for lambdas planned for at least JDK10 [0]. Is what I asked for below maybe a candidate for inclusion into those efforts? >> >> Is there maybe a better place to ask for this? >> >> Cheers, >> Ollie >> >> [0] https://www.infoq.com/news/2017/01/java10-lambda-leftovers >> >>> Am 23.12.2016 um 12:22 schrieb Oliver Gierke : >>> >>> Hi all, >>> >>> Lambda based implementations of SAM types currently don't support inspecting the type for generic type parameters. This can cause unexpected surprise as some high-level API taking a SAM type as parameter is usually an indicator to users, that they can be used with Lambdas. If the object passed in is then inspected for generic types somewhere down the call stack this causes issues. Handing in a dedicated implementation of the SAM type is a workaround bit I think that's highly confusing and can be a source of errors hard to understand and debug. >>> >>> I've added an example below. >>> >>> Cheers, >>> Ollie >>> >>> public class LambdaTypeDetectionSample { >>> >>> public static void main(String[] args) { >>> >>> Function lambdaFunction = i -> i.toString(); >>> Function oldschoolFunction = new Function() { >>> >>> public String apply(Integer t) { >>> return t.toString(); >>> } >>> }; >>> >>> printTypeArguments(oldschoolFunction); >>> >>> // Yields: >>> // java.util.function.Function is a class sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl >>> // class java.lang.Integer >>> // class java.lang.String >>> >>> printTypeArguments(lambdaFunction); >>> >>> // Yields: >>> // interface java.util.function.Function is a class java.lang.Class >>> } >>> >>> private static void printTypeArguments(Function function) { >>> >>> Type type = function.getClass().getGenericInterfaces()[0]; >>> >>> System.out.println(type + " is a " + type.getClass()); >>> >>> if (type instanceof ParameterizedType) { >>> >>> ParameterizedType functionInterface = (ParameterizedType) type; >>> Arrays.stream(functionInterface.getActualTypeArguments()).forEach(System.out::println); >>> } >>> } >>> } > -------------- 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 bsrbnd at gmail.com Thu Jan 19 13:44:04 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 19 Jan 2017 14:44:04 +0100 Subject: Incoherent invocation type inference? In-Reply-To: <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> Message-ID: Hi, 2017-01-15 12:45 GMT+01:00 Remi Forax : > Inference of 0-arity methods in Java is due to the fact that generics were introduced after the collection API in Java, and an explicit goal of the specification of generics was to be able to retrofit classes of java.util. > > An unsafe warning means that you may get a ClassCastException at runtime. > > In the collection API, you have methods like Collections.emptyList() that has to return different types depending on the calling context. > Calling those methods should not emit a warning because you can not have a CCE at runtime, if you call a method that takes an E will have get an UnsupportedException, if you call a methods that returns an E you will get an IndexOutOfBoundsException or a NoSuchElementException. So you may get a lot of different exceptions but not a CCE, so a call to Collections.emptyList() is safe (with the current definition of what safe means) and the compiler should not trigger any warning. > As noted by Maurizio further in the thread, a warning might be interesting when a retun value is expected and a naked type variable is returned with no constraint given by the actual arguments; because the invoked method wouldn't know about the return type constraint. The collection API you mentioned wouldn't probably be concerned, as most 0-arity methods don't return any naked type variable. Nevertheless, List declares an interesting method: T[] toArray(T[] a); In the current implementation of ArrayList, if we write something like: List l = new ArrayList(); l.add("test"); String[] sa = new String[1]; sa = l.toArray(null); // NullPointerException Integer[] ia = new Integer[1]; ia = l.toArray(null); // NullPointerException ... we get a NullPointerException. We could imagine another implementation that would invoke "Object[] toArray()" if "a==null". In that case we would get a ClassCastException. In all cases, this piece of code will fail at runtime with any exception. Then, javac could probably emit also a warning in this situation by updating the rule as follows: "emit a Lint warning if a return value is expected and the return type T is a naked type variable or an array of a naked type variable and no constraint is given by the actual arguments". The following draft is a suggestion for the implementation of this rule (Infer.instantiateMethod() upon rev. b6960e2da008). What's your opinion on that? Thanks, Bernard > C# is different because if you declare a static field instead of having one static value, you have one static value by type argument, > so for C#, it makes sense to force users to specify the type argument given that the returned value will be different. > > The problem of the code of Bernard is not related to the inference, the problem is the unsafe cast in the implementation, if you use an unsafe cast, then you may have a ClassCastException at runtime. It's as simple as that. > > regards, > R?mi diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java @@ -182,6 +182,30 @@ final InferenceContext inferenceContext = new InferenceContext(this, tvars); //B0 inferenceException.clear(); try { + Type elemResType = mt.restype; + while (elemResType.hasTag(ARRAY)) { + elemResType = ((ArrayType)elemResType).elemtype; + } + if (resultInfo != null && resultInfo.pt != Type.noType && elemResType.hasTag(TYPEVAR)) { + int nbConstraints = 0; + if (mt.argtypes.length() <= argtypes.length()) { + for (int i=0; i References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> Message-ID: <75813168-13e4-141c-d9f6-4d4df112f1d3@oracle.com> On 19/01/17 13:44, B. Blaser wrote: > ... we get a NullPointerException. We could imagine another > implementation that would invoke "Object[] toArray()" if "a==null". In > that case we would get a ClassCastException. In all cases, this piece > of code will fail at runtime with any exception. Then, javac could > probably emit also a warning in this situation by updating the rule as > follows: I don't think I agree with your analysis. Yes, an impl could delegate to toArray() but then will have to cast from Object[] to T[], which is an unchecked cast - so a CCE would be well deserved there. Maurizio From maurizio.cimadamore at oracle.com Thu Jan 19 17:22:59 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 19 Jan 2017 17:22:59 +0000 Subject: Incoherent invocation type inference? In-Reply-To: References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> <43f3f78e-73ef-e54d-91dc-47f2b56b2e8b@oracle.com> <7d0167b4-6085-9256-7073-61e9bf9ddfdb@oracle.com> <42944d98-ef8d-5f29-32aa-cac5581f96f5@oracle.com> Message-ID: <6ab2395d-ffd3-8437-2c57-a93d357e3c15@oracle.com> Not sure about your proposed patch. To me the warning should be a property of the method declaration, not of the specific inference. If a method returns a naked type-variable which is not mentioned anywhere in the method parameter types -> Lint warning (not an unchecked warning - just an optional Lint one - category TBD). It's true that, by looking at the callsite, you can also warn for clients passing 'null' arguments, but the extra benefit is not worth the extra complexity IMHO. And, I think this is a problem of bad API, not one of bad clients. A well-designed API should not have any methods that match the criteria stated above - as their behavior would ultimately be at the client's mercy. Maurizio On 18/01/17 12:50, B. Blaser wrote: > Hi, > > 2017-01-16 19:33 GMT+01:00 B. Blaser : >> 2017-01-16 18:03 GMT+01:00 Maurizio Cimadamore : >>> On 16/01/17 16:49, B. Blaser wrote: >>>> Intersections seem to be dangerous only in the case of a naked return >>>> type variable with no parameter provided ("get()" or "get(null)") >>>> because get() wouldn't know about the return type constraints. We >>>> could, for example, update the rule as follows: "emit a lint warning >>>> if the return type T is a naked type variable infered to an >>>> intersection type and no constraint is given by the actual arguments"? >>>> >>>> Or are you suggesting to modify the rules of intersection types on the >>>> language side? >>> I think the Lint warning makes sense for naked return type regardless of >>> intersections - as in the example I wrote. >> Ok for this first rule. > What do you think of something like the draft below > (Infer.instantiateMethod() upon rev. b6960e2da008)? > Thanks, > Bernard > >>> Maurizio > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java > @@ -182,6 +182,26 @@ > final InferenceContext inferenceContext = new > InferenceContext(this, tvars); //B0 > inferenceException.clear(); > try { > + if (resultInfo != null && resultInfo.pt != Type.noType && > mt.restype.hasTag(TYPEVAR)) { > + int nbConstraints = 0; > + if (mt.argtypes.length() == argtypes.length()) { > + for (int i=0; i + Type pType = mt.argtypes.get(i); > + Type aType = argtypes.get(i); > + if (pType.contains(mt.restype) && aType != > syms.botType) > + nbConstraints++; > + } > + } > + if (nbConstraints == 0) { > + chk.warnUnchecked(env.tree.pos(), > + "unchecked.invocation.type.inference", > + Kinds.kindName(msym), > + msym.name, > + Kinds.kindName(msym.location()), > + msym.location()); > + } > + } > + > DeferredAttr.DeferredAttrContext deferredAttrContext = > resolveContext.deferredAttrContext(msym, > inferenceContext, resultInfo, warn); > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties > @@ -1748,6 +1748,10 @@ > required: {2}\n\ > found: {3} > > +# 0: symbol kind, 1: name, 2: symbol kind, 3: symbol > +compiler.warn.unchecked.invocation.type.inference=\ > + unchecked invocation type inference: {0} {1} in {2} {3} misses > constraints from actual arguments > + > # 0: type > compiler.warn.unchecked.generic.array.creation=\ > unchecked generic array creation for varargs parameter of type {0} From bruno.rosa at eldorado.org.br Fri Jan 20 18:42:51 2017 From: bruno.rosa at eldorado.org.br (Bruno Alexandre Rosa) Date: Fri, 20 Jan 2017 18:42:51 +0000 Subject: Enforcing data alignment for intrinsics Message-ID: <920cb730922f42c5a1585fcae6aeb7a8@serv031.corp.eldorado.org.br> Hi all, Currently I'm working on a patch to implement SHA2 intrinsics for ppc64 and came upon this issue: vector load instructions (lvx) assume that the data is 16bytes-aligned. It is possible to access unaligned data, but that requires more than just one instruction, incurring in a performance loss. Is it possible to enforce 16bytes alignment for the input buffer available to the intrinsics? If it is so, can someone give me pointers for making this change? Regards, Bruno Rosa From bruno.rosa at eldorado.org.br Fri Jan 20 18:45:25 2017 From: bruno.rosa at eldorado.org.br (Bruno Alexandre Rosa) Date: Fri, 20 Jan 2017 18:45:25 +0000 Subject: Enforcing data alignment for intrinsics In-Reply-To: <920cb730922f42c5a1585fcae6aeb7a8@serv031.corp.eldorado.org.br> References: <920cb730922f42c5a1585fcae6aeb7a8@serv031.corp.eldorado.org.br> Message-ID: Oops, wrong mailing list. Sorry. Already forward it to hotspot-compiler-dev at openjdk.java.net :) Regards, Bruno Rosa -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Bruno Alexandre Rosa Sent: sexta-feira, 20 de janeiro de 2017 16:43 To: compiler-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Enforcing data alignment for intrinsics Hi all, Currently I'm working on a patch to implement SHA2 intrinsics for ppc64 and came upon this issue: vector load instructions (lvx) assume that the data is 16bytes-aligned. It is possible to access unaligned data, but that requires more than just one instruction, incurring in a performance loss. Is it possible to enforce 16bytes alignment for the input buffer available to the intrinsics? If it is so, can someone give me pointers for making this change? Regards, Bruno Rosa From ittaiz at gmail.com Sun Jan 22 06:25:47 2017 From: ittaiz at gmail.com (ittai zeidman) Date: Sun, 22 Jan 2017 06:25:47 +0000 Subject: Finding out unused classpath entries Message-ID: Hi, I'm trying to migrate a codebase from a coarse granularity to a finer grain one. One of the issues is identifying what is actually needed for compile time for each of the smaller units. Given that in some cases there is a need for compile time dependencies which don't later appear in the source or bytecode of the output I'm trying to ascertain if there is a way for me to know which class-path entries were actually used during a javac invocation. My intention is to break the coarse grain module to many smaller ones where each of the smaller ones depends on the full transitive closure of the external jars the original module depended on. My hope is then to run javac with some kind of flag which will allow me to derive the actual set of class-path entries used for that specific fine grain module. It seems I might be able to use -verbose to do this but I'd appreciate knowing if there is an easier way and if not then a pointer to the formatting of these messages would also be appreciated. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Sun Jan 22 16:26:44 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 22 Jan 2017 17:26:44 +0100 Subject: Incoherent invocation type inference? In-Reply-To: <6ab2395d-ffd3-8437-2c57-a93d357e3c15@oracle.com> References: <5e5ae04c-e442-7925-0fae-8544376ffd54@oracle.com> <1197680659.2383392.1484480737965.JavaMail.zimbra@u-pem.fr> <43f3f78e-73ef-e54d-91dc-47f2b56b2e8b@oracle.com> <7d0167b4-6085-9256-7073-61e9bf9ddfdb@oracle.com> <42944d98-ef8d-5f29-32aa-cac5581f96f5@oracle.com> <6ab2395d-ffd3-8437-2c57-a93d357e3c15@oracle.com> Message-ID: Hi, 2017-01-19 18:22 GMT+01:00 Maurizio Cimadamore : > Not sure about your proposed patch. > > To me the warning should be a property of the method declaration, not of the > specific inference. > > If a method returns a naked type-variable which is not mentioned anywhere in > the method parameter types -> Lint warning (not an unchecked warning - just > an optional Lint one - category TBD). > > It's true that, by looking at the callsite, you can also warn for clients > passing 'null' arguments, but the extra benefit is not worth the extra > complexity IMHO. And, I think this is a problem of bad API, not one of bad > clients. A well-designed API should not have any methods that match the > criteria stated above - as their behavior would ultimately be at the > client's mercy. > > Maurizio Here under is a suggestion for the implementation of the rule you stated above (Attr.visitMethodDef(), upon rev. b6960e2da008). I kept a check on the callsite for further evaluation (in Attr.checkMethod() to be more general). I think both are complementary. " T[] List.toArray(T[])" is a good example of a well designed API. But an invocation of the form "a = l.toArray(null)" is dangerous due to the obvious API's lack of control over T and might be warned. For the Lint category, I suggest to name it "generic" and to use it for warnings about type variables. Other checks like the "final" one could fall into the same category. Does this look better? Thanks, Bernard diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java @@ -268,6 +268,11 @@ UNCHECKED("unchecked"), /** + * Warn about issues relating to type variables. + */ + GENERIC("generic"), + + /** * Warn about potentially unsafe vararg methods */ VARARGS("varargs"); diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java @@ -947,6 +947,7 @@ deferredLintHandler.flush(tree.pos()); chk.checkDeprecatedAnnotation(tree.pos(), m); + chk.checkGenMethDeclaration(tree.pos(), m); // Create a new environment with local scope // for attributing the method. @@ -3918,6 +3919,8 @@ final List argtrees, List argtypes, List typeargtypes) { + chk.checkGenMethInvocation(env.tree.pos(), sym, resultInfo, argtypes); + // Test (5): if symbol is an instance method of a raw type, issue // an unchecked warning if its argument types change under erasure. if ((sym.flags() & STATIC) == 0 && diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java @@ -3876,4 +3876,76 @@ } } + // Check the declaration's precision for type variables. + void checkGenMethDeclaration(DiagnosticPosition pos, Symbol sym) { + if (sym.type.hasTag(FORALL)) { + ForAll gmt = (ForAll)sym.type; + MethodType mt = (MethodType)gmt.qtype; + List tvars = gmt.tvars; + + Type elemResType = mt.restype; + while (elemResType.hasTag(ARRAY)) { + elemResType = ((ArrayType)elemResType).elemtype; + } + if (elemResType.hasTag(TYPEVAR) && tvars.contains(elemResType)) { + boolean ok = false; + for (Type t: mt.argtypes) { + if (t.contains(elemResType)) + ok = true; + } + if (!ok) + warnGeneric( + pos, + "generic.imprecise.method.declaration", + Kinds.kindName(sym), + sym.name, + Kinds.kindName(sym.location()), + sym.location(), + elemResType); + } + } + } + + // Check the actual arguments' precision for type variables. + void checkGenMethInvocation( + DiagnosticPosition pos, + Symbol sym, + Attr.ResultInfo resultInfo, + List argtypes) { + + if (sym.type.hasTag(FORALL)) { + ForAll gmt = (ForAll)sym.type; + MethodType mt = (MethodType)gmt.qtype; + + Type elemResType = mt.restype; + while (elemResType.hasTag(ARRAY)) { + elemResType = ((ArrayType)elemResType).elemtype; + } + if (resultInfo != null && resultInfo.pt != Type.noType && elemResType.hasTag(TYPEVAR)) { + boolean ok = false; + if (mt.argtypes.length() <= argtypes.length()) { + for (int i=0; i Hello, Even after the fixes for JDK-8172458, there is still a lingering HTML5 compliance issue in javax.lang.model.* in addition to a few javadoc linkage problems. These should all be fixed; small patch below. With the patch, the code is doclint clean under both HTML 4.01 and HTML 5 output. (I thought the linkage problem would have been caught by the javac and javadoc build options, but apparently not.) Thanks, -Joe diff -r 50c877258ca9 src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java --- a/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java Fri Jan 20 18:24:50 2017 -0800 +++ b/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java Sun Jan 22 16:23:28 2017 -0800 @@ -35,7 +35,7 @@ * type is a kind of class and an annotation type is a kind of * interface. * - *

+ *

* While a {@code TypeElement} represents a class or interface * element, a {@link DeclaredType} represents a class * or interface type, the latter being a use diff -r 50c877258ca9 src/java.compiler/share/classes/javax/lang/model/util/Elements.java --- a/src/java.compiler/share/classes/javax/lang/model/util/Elements.java Fri Jan 20 18:24:50 2017 -0800 +++ b/src/java.compiler/share/classes/javax/lang/model/util/Elements.java Sun Jan 22 16:23:28 2017 -0800 @@ -29,6 +29,7 @@ import java.util.List; import java.util.Map; +import javax.annotation.processing.ProcessingEnvironment; import javax.lang.model.AnnotatedConstruct; import javax.lang.model.element.*; @@ -91,7 +92,7 @@ * If the named module cannot be found, null is returned. One situation where a module * cannot be found is if the environment does not include modules, such as * an annotation processing environment configured for - * a {@linkplain ProcessingEnvironment#getSourceVersion source version} without modules. * + * a {@linkplain ProcessingEnvironment#getSourceVersion source version} without modules. * * @param name the name * @return the named module element, or {@code null} if it cannot be found @@ -331,7 +332,7 @@ * If there is no module for the element, null is returned. One situation where there is * no module for an element is if the environment does not include modules, such as * an annotation processing environment configured for - * a {@linkplain ProcessingEnvironment#getSourceVersion source version} without modules. * + * a {@linkplain ProcessingEnvironment#getSourceVersion source version} without modules. * * @param type the element being examined * @return the module of an element From zlob.jc at gmail.com Mon Jan 23 09:15:09 2017 From: zlob.jc at gmail.com (zlob jc) Date: Mon, 23 Jan 2017 12:15:09 +0300 Subject: Compiler NPE com.sun.tools.javac.code.Types.removeWildcards(Types.java:601) Message-ID: Right now we are building our project with IDEA on dev and Ant-script on CI. But we consider to switch to maven and have issue with compiler bug when we try to build project with Maven. We try jdk 1.8.0_65, 1.8.0_111, 1.8.0_121 and various versions of maven compiler plugin results are the same. This module has hight coupling and we can't localize root of issue yet, so we have no sample code to reproduce this. Any help are welcome. java -version java version "1.8.0_121" Java(TM) SE Runtime Environment (build 1.8.0_121-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) mvn -version Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T19:41:47+03:00) Maven home: C:\Program Files\Maven Java version: 1.8.0_121, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.8.0_121\jre Default locale: ru_RU, platform encoding: Cp1251 OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos" Full log https://gist.github.com/zlobjc/4f6885a0e5114542cafabe7fe496836b --- maven-compiler-plugin:3.6.0:compile (default-compile) @ --- Changes detected - recompiling the module! Compiling 3190 source files to E:\\target\classes An exception has occurred in the compiler (1.8.0_111). java.lang.NullPointerException at com.sun.tools.javac.code.Types.removeWildcards(Types.java:601) -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Mon Jan 23 16:57:27 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 Jan 2017 08:57:27 -0800 Subject: JDK 9 RFR of JDK-8173164: Resolve remaining HTML5 issues in javax.lang.model.* In-Reply-To: References: Message-ID: It's good. There's a persistent ecosystem nuisance that tools don't recognize imports done purely for javadoc's benefit and complain. For this reason I generally use fully qualified @links in the javadoc, even though it's uglier. On Sun, Jan 22, 2017 at 4:45 PM, joe darcy wrote: > Hello, > > Even after the fixes for JDK-8172458, there is still a lingering HTML5 > compliance issue in javax.lang.model.* in addition to a few javadoc linkage > problems. These should all be fixed; small patch below. > > With the patch, the code is doclint clean under both HTML 4.01 and HTML 5 > output. > > (I thought the linkage problem would have been caught by the javac and > javadoc build options, but apparently not.) > > Thanks, > > -Joe > > diff -r 50c877258ca9 src/java.compiler/share/classe > s/javax/lang/model/element/TypeElement.java > --- a/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > Fri Jan 20 18:24:50 2017 -0800 > +++ b/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > Sun Jan 22 16:23:28 2017 -0800 > @@ -35,7 +35,7 @@ > * type is a kind of class and an annotation type is a kind of > * interface. > * > - *

> + *

> * While a {@code TypeElement} represents a class or interface > * element, a {@link DeclaredType} represents a class > * or interface type, the latter being a use > diff -r 50c877258ca9 src/java.compiler/share/classe > s/javax/lang/model/util/Elements.java > --- a/src/java.compiler/share/classes/javax/lang/model/util/Elements.java > Fri Jan 20 18:24:50 2017 -0800 > +++ b/src/java.compiler/share/classes/javax/lang/model/util/Elements.java > Sun Jan 22 16:23:28 2017 -0800 > @@ -29,6 +29,7 @@ > import java.util.List; > import java.util.Map; > > +import javax.annotation.processing.ProcessingEnvironment; > import javax.lang.model.AnnotatedConstruct; > import javax.lang.model.element.*; > > @@ -91,7 +92,7 @@ > * If the named module cannot be found, null is returned. One > situation where a module > * cannot be found is if the environment does not include modules, > such as > * an annotation processing environment configured for > - * a {@linkplain ProcessingEnvironment#getSourceVersion source > version} without modules. * > + * a {@linkplain ProcessingEnvironment#getSourceVersion source > version} without modules. > * > * @param name the name > * @return the named module element, or {@code null} if it cannot be > found > @@ -331,7 +332,7 @@ > * If there is no module for the element, null is returned. One > situation where there is > * no module for an element is if the environment does not include > modules, such as > * an annotation processing environment configured for > - * a {@linkplain ProcessingEnvironment#getSourceVersion source > version} without modules. * > + * a {@linkplain ProcessingEnvironment#getSourceVersion source > version} without modules. > * > * @param type the element being examined > * @return the module of an element > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Mon Jan 23 18:22:12 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 23 Jan 2017 10:22:12 -0800 Subject: JDK 9 RFR of JDK-8173164: Resolve remaining HTML5 issues in javax.lang.model.* In-Reply-To: References: Message-ID: <24dd72b9-34bc-ecfc-3bd0-bb72e936889f@oracle.com> Hi Martin, Thanks for the review. For better tooling interaction, I'll switch to the fully qualified name for the links. Also, upon closer examination, there are not incoming links to the anchor so I'll just delete it. Updated patch below. Thanks, -Joe diff -r 50c877258ca9 src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java --- a/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java Fri Jan 20 18:24:50 2017 -0800 +++ b/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java Mon Jan 23 10:19:24 2017 -0800 @@ -35,8 +35,7 @@ * type is a kind of class and an annotation type is a kind of * interface. * - *

- * While a {@code TypeElement} represents a class or interface + *

While a {@code TypeElement} represents a class or interface * element, a {@link DeclaredType} represents a class * or interface type, the latter being a use * (or invocation) of the former. diff -r 50c877258ca9 src/java.compiler/share/classes/javax/lang/model/util/Elements.java --- a/src/java.compiler/share/classes/javax/lang/model/util/Elements.java Fri Jan 20 18:24:50 2017 -0800 +++ b/src/java.compiler/share/classes/javax/lang/model/util/Elements.java Mon Jan 23 10:19:24 2017 -0800 @@ -91,7 +91,9 @@ * If the named module cannot be found, null is returned. One situation where a module * cannot be found is if the environment does not include modules, such as * an annotation processing environment configured for - * a {@linkplain ProcessingEnvironment#getSourceVersion source version} without modules. * + * a {@linkplain + * javax.annotation.processing.ProcessingEnvironment#getSourceVersion + * source version} without modules. * * @param name the name * @return the named module element, or {@code null} if it cannot be found @@ -331,7 +333,9 @@ * If there is no module for the element, null is returned. One situation where there is * no module for an element is if the environment does not include modules, such as * an annotation processing environment configured for - * a {@linkplain ProcessingEnvironment#getSourceVersion source version} without modules. * + * a {@linkplain + * javax.annotation.processing.ProcessingEnvironment#getSourceVersion + * source version} without modules. * * @param type the element being examined * @return the module of an element On 1/23/2017 8:57 AM, Martin Buchholz wrote: > It's good. > > There's a persistent ecosystem nuisance that tools don't recognize > imports done purely for javadoc's benefit and complain. For this > reason I generally use fully qualified @links in the javadoc, even > though it's uglier. > > > On Sun, Jan 22, 2017 at 4:45 PM, joe darcy > wrote: > > Hello, > > Even after the fixes for JDK-8172458, there is still a lingering > HTML5 compliance issue in javax.lang.model.* in addition to a few > javadoc linkage problems. These should all be fixed; small patch > below. > > With the patch, the code is doclint clean under both HTML 4.01 and > HTML 5 output. > > (I thought the linkage problem would have been caught by the javac > and javadoc build options, but apparently not.) > > Thanks, > > -Joe > > diff -r 50c877258ca9 > src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > --- > a/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > Fri Jan 20 18:24:50 2017 -0800 > +++ > b/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > Sun Jan 22 16:23:28 2017 -0800 > @@ -35,7 +35,7 @@ > * type is a kind of class and an annotation type is a kind of > * interface. > * > - *

> + *

> * While a {@code TypeElement} represents a class or interface > * element, a {@link DeclaredType} represents a class > * or interface type, the latter being a use > diff -r 50c877258ca9 > src/java.compiler/share/classes/javax/lang/model/util/Elements.java > --- > a/src/java.compiler/share/classes/javax/lang/model/util/Elements.java > Fri Jan 20 18:24:50 2017 -0800 > +++ > b/src/java.compiler/share/classes/javax/lang/model/util/Elements.java > Sun Jan 22 16:23:28 2017 -0800 > @@ -29,6 +29,7 @@ > import java.util.List; > import java.util.Map; > > +import javax.annotation.processing.Pr > ocessingEnvironment; > import javax.lang.model.AnnotatedConstruct; > import javax.lang.model.element.*; > > @@ -91,7 +92,7 @@ > * If the named module cannot be found, null is returned. One > situation where a module > * cannot be found is if the environment does not include > modules, such as > * an annotation processing environment configured for > - * a {@linkplain ProcessingEnvironment#getSourceVersion > source version} without modules. * > + * a {@linkplain ProcessingEnvironment#getSourceVersion > source version} without modules. > * > * @param name the name > * @return the named module element, or {@code null} if it > cannot be found > @@ -331,7 +332,7 @@ > * If there is no module for the element, null is returned. > One situation where there is > * no module for an element is if the environment does not > include modules, such as > * an annotation processing environment configured for > - * a {@linkplain ProcessingEnvironment#getSourceVersion > source version} without modules. * > + * a {@linkplain ProcessingEnvironment#getSourceVersion > source version} without modules. > * > * @param type the element being examined > * @return the module of an element > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Tue Jan 24 06:37:39 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 23 Jan 2017 22:37:39 -0800 Subject: JDK 9 RFR of JDK-8173164: Resolve remaining HTML5 issues in javax.lang.model.* In-Reply-To: <24dd72b9-34bc-ecfc-3bd0-bb72e936889f@oracle.com> References: <24dd72b9-34bc-ecfc-3bd0-bb72e936889f@oracle.com> Message-ID: Looks good. On Mon, Jan 23, 2017 at 10:22 AM, joe darcy wrote: > Hi Martin, > > Thanks for the review. > > For better tooling interaction, I'll switch to the fully qualified name > for the links. > > Also, upon closer examination, there are not incoming links to the anchor > so I'll just delete it. > > Updated patch below. > > Thanks, > > -Joe > > diff -r 50c877258ca9 src/java.compiler/share/classes/javax/lang/model/ > element/TypeElement.java > --- a/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > Fri Jan 20 18:24:50 2017 -0800 > +++ b/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java > Mon Jan 23 10:19:24 2017 -0800 > @@ -35,8 +35,7 @@ > * type is a kind of class and an annotation type is a kind of > * interface. > * > - *

> - * While a {@code TypeElement} represents a class or interface > + *

While a {@code TypeElement} represents a class or interface > * element, a {@link DeclaredType} represents a class > * or interface type, the latter being a use > * (or invocation) of the former. > diff -r 50c877258ca9 src/java.compiler/share/ > classes/javax/lang/model/util/Elements.java > --- a/src/java.compiler/share/classes/javax/lang/model/util/Elements.java > Fri Jan 20 18:24:50 2017 -0800 > +++ b/src/java.compiler/share/classes/javax/lang/model/util/Elements.java > Mon Jan 23 10:19:24 2017 -0800 > @@ -91,7 +91,9 @@ > * If the named module cannot be found, null is returned. One > situation where a module > * cannot be found is if the environment does not include modules, > such as > * an annotation processing environment configured for > - * a {@linkplain ProcessingEnvironment#getSourceVersion source > version} without modules. * > + * a {@linkplain > + * javax.annotation.processing.ProcessingEnvironment#getSourceVersion > + * source version} without modules. > * > * @param name the name > * @return the named module element, or {@code null} if it cannot be > found > @@ -331,7 +333,9 @@ > * If there is no module for the element, null is returned. One > situation where there is > * no module for an element is if the environment does not include > modules, such as > * an annotation processing environment configured for > - * a {@linkplain ProcessingEnvironment#getSourceVersion source > version} without modules. * > + * a {@linkplain > + * javax.annotation.processing.ProcessingEnvironment#getSourceVersion > + * source version} without modules. > * > * @param type the element being examined > * @return the module of an element > > > On 1/23/2017 8:57 AM, Martin Buchholz wrote: > > It's good. > > There's a persistent ecosystem nuisance that tools don't recognize imports > done purely for javadoc's benefit and complain. For this reason I > generally use fully qualified @links in the javadoc, even though it's > uglier. > > > On Sun, Jan 22, 2017 at 4:45 PM, joe darcy wrote: > >> Hello, >> >> Even after the fixes for JDK-8172458, there is still a lingering HTML5 >> compliance issue in javax.lang.model.* in addition to a few javadoc linkage >> problems. These should all be fixed; small patch below. >> >> With the patch, the code is doclint clean under both HTML 4.01 and HTML 5 >> output. >> >> (I thought the linkage problem would have been caught by the javac and >> javadoc build options, but apparently not.) >> >> Thanks, >> >> -Joe >> >> diff -r 50c877258ca9 src/java.compiler/share/classe >> s/javax/lang/model/element/TypeElement.java >> --- a/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java >> Fri Jan 20 18:24:50 2017 -0800 >> +++ b/src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java >> Sun Jan 22 16:23:28 2017 -0800 >> @@ -35,7 +35,7 @@ >> * type is a kind of class and an annotation type is a kind of >> * interface. >> * >> - *

>> + *

>> * While a {@code TypeElement} represents a class or interface >> * element, a {@link DeclaredType} represents a class >> * or interface type, the latter being a use >> diff -r 50c877258ca9 src/java.compiler/share/classe >> s/javax/lang/model/util/Elements.java >> --- a/src/java.compiler/share/classes/javax/lang/model/util/Elements.java >> Fri Jan 20 18:24:50 2017 -0800 >> +++ b/src/java.compiler/share/classes/javax/lang/model/util/Elements.java >> Sun Jan 22 16:23:28 2017 -0800 >> @@ -29,6 +29,7 @@ >> import java.util.List; >> import java.util.Map; >> >> +import javax.annotation.processing.ProcessingEnvironment; >> import javax.lang.model.AnnotatedConstruct; >> import javax.lang.model.element.*; >> >> @@ -91,7 +92,7 @@ >> * If the named module cannot be found, null is returned. One >> situation where a module >> * cannot be found is if the environment does not include modules, >> such as >> * an annotation processing environment configured for >> - * a {@linkplain ProcessingEnvironment#getSourceVersion source >> version} without modules. * >> + * a {@linkplain ProcessingEnvironment#getSourceVersion source >> version} without modules. >> * >> * @param name the name >> * @return the named module element, or {@code null} if it cannot be >> found >> @@ -331,7 +332,7 @@ >> * If there is no module for the element, null is returned. One >> situation where there is >> * no module for an element is if the environment does not include >> modules, such as >> * an annotation processing environment configured for >> - * a {@linkplain ProcessingEnvironment#getSourceVersion source >> version} without modules. * >> + * a {@linkplain ProcessingEnvironment#getSourceVersion source >> version} without modules. >> * >> * @param type the element being examined >> * @return the module of an element >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue Jan 24 10:59:18 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 24 Jan 2017 11:59:18 +0100 (CET) Subject: javac bug when calling javac from the ToolProvider Message-ID: <1522003424.637528.1485255558390.JavaMail.zimbra@u-pem.fr> Hi all, when calling javac from the ToolProvider, i get a NPE with the jdkb152/b153. in getLocationForModule(Path), pathLocations can be null Location getLocationForModule(Path dir) { return pathLocations.get(dir); } getLocationForModule(String) detects that pathLocations may be null and acts accordingly, but there is no such check in getLocationForModule(Path). another question is why the behavior of javac is different when calling by the ToolProvider than using the main. cheers, R?mi java.lang.NullPointerException at jdk.compiler/com.sun.tools.javac.file.Locations$OutputLocationHandler.getLocationForModule(Locations.java:556) at jdk.compiler/com.sun.tools.javac.file.Locations.getLocationForModule(Locations.java:1664) at jdk.compiler/com.sun.tools.javac.file.JavacFileManager.getLocationForModule(JavacFileManager.java:996) at jdk.compiler/com.sun.tools.javac.comp.Modules.getModuleLocation(Modules.java:482) at jdk.compiler/com.sun.tools.javac.comp.Modules.getModuleLocation(Modules.java:465) at jdk.compiler/com.sun.tools.javac.comp.Modules.setCompilationUnitModules(Modules.java:366) at jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:265) at jdk.compiler/com.sun.tools.javac.comp.Modules.initModules(Modules.java:231) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.initModules(JavaCompiler.java:1043) at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:937) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:307) at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:160) at jdk.compiler/com.sun.tools.javac.main.JavacToolProvider.run(JavacToolProvider.java:46) at java.base/java.util.spi.ToolProvider.run(ToolProvider.java:137) at com.github.forax.pro.plugin.compiler at 0.9/com.github.forax.pro.plugin.compiler.CompilerPlugin.compile(CompilerPlugin.java:178) at com.github.forax.pro.plugin.compiler at 0.9/com.github.forax.pro.plugin.compiler.CompilerPlugin.execute(CompilerPlugin.java:108) at com.github.forax.pro at 0.9/com.github.forax.pro.Pro.execute(Pro.java:257) at com.github.forax.pro at 0.9/com.github.forax.pro.Pro.runAll(Pro.java:237) at com.github.forax.pro at 0.9/com.github.forax.pro.Pro.run(Pro.java:227) at com.github.forax.pro.main at 0.9/com.github.forax.pro.main.JSONConfigRunner.run(JSONConfigRunner.java:68) at com.github.forax.pro.main at 0.9/com.github.forax.pro.main.JSONConfigRunner.lambda$accept$0(JSONConfigRunner.java:22) at com.github.forax.pro.main at 0.9/com.github.forax.pro.main.Main.build(Main.java:122) at com.github.forax.pro.main at 0.9/com.github.forax.pro.main.Main.main(Main.java:166) From Alan.Bateman at oracle.com Tue Jan 24 11:08:41 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Jan 2017 11:08:41 +0000 Subject: javac bug when calling javac from the ToolProvider In-Reply-To: <1522003424.637528.1485255558390.JavaMail.zimbra@u-pem.fr> References: <1522003424.637528.1485255558390.JavaMail.zimbra@u-pem.fr> Message-ID: <023ffa56-7e6d-4bda-542b-b81477f9d736@oracle.com> On 24/01/2017 10:59, Remi Forax wrote: > Hi all, > when calling javac from the ToolProvider, i get a NPE with the jdkb152/b153. > > in getLocationForModule(Path), pathLocations can be null > Location getLocationForModule(Path dir) { > return pathLocations.get(dir); > } > > getLocationForModule(String) detects that pathLocations may be null and acts accordingly, > but there is no such check in getLocationForModule(Path). > This looks like similar to JDK-8172785 [1] which is fixed in jdk9/dev for jdk-9+154. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8172785 From forax at univ-mlv.fr Tue Jan 24 11:12:18 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 24 Jan 2017 12:12:18 +0100 (CET) Subject: javac bug when calling javac from the ToolProvider In-Reply-To: <023ffa56-7e6d-4bda-542b-b81477f9d736@oracle.com> References: <1522003424.637528.1485255558390.JavaMail.zimbra@u-pem.fr> <023ffa56-7e6d-4bda-542b-b81477f9d736@oracle.com> Message-ID: <193994942.645744.1485256338086.JavaMail.zimbra@u-pem.fr> Thanks Alan, yes, it's the same bug ! i was not able to find it in the database, R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Remi Forax" > Cc: "jigsaw-dev" , "compiler-dev" > Envoy?: Mardi 24 Janvier 2017 12:08:41 > Objet: Re: javac bug when calling javac from the ToolProvider > On 24/01/2017 10:59, Remi Forax wrote: > >> Hi all, >> when calling javac from the ToolProvider, i get a NPE with the jdkb152/b153. >> >> in getLocationForModule(Path), pathLocations can be null >> Location getLocationForModule(Path dir) { >> return pathLocations.get(dir); >> } >> >> getLocationForModule(String) detects that pathLocations may be null and acts >> accordingly, >> but there is no such check in getLocationForModule(Path). >> > This looks like similar to JDK-8172785 [1] which is fixed in jdk9/dev > for jdk-9+154. > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-8172785 From jan.lahoda at oracle.com Tue Jan 24 14:35:23 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 24 Jan 2017 15:35:23 +0100 Subject: RFR: JDK-8171294: Slow compilation with long classpaths under JDK 9 Message-ID: <5887662B.8030702@oracle.com> 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 Jan 25 01:37:48 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 24 Jan 2017 17:37:48 -0800 Subject: [Patch] 8041793: javap misses newline after printing AnnotationDefault In-Reply-To: References: <587991F0.8070904@oracle.com> Message-ID: <5888016C.4040300@oracle.com> On 01/15/2017 11:34 AM, Denis Istomin wrote: > Fixed test: > 1. Using getOutputLines instead of getOutput > 2. Using toolbox.Assert class with error message instead of throwing > simple "Error". > Denis, Reviewed and pushed. Thanks. -- Jon From jonathan.gibbons at oracle.com Wed Jan 25 01:38:33 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 24 Jan 2017 17:38:33 -0800 Subject: [Patch] 8051768: Inconsistent output for Visible and InvisibleParameterAnnotations In-Reply-To: References: <487145553.1847977.1484291907043.JavaMail.zimbra@u-pem.fr> <58799282.6070905@oracle.com> Message-ID: <58880199.90904@oracle.com> On 01/15/2017 01:16 PM, Denis Istomin wrote: > Fixed newlines and error message. > > -- > Denis Istomin > > 2017-01-14 7:52 GMT+05:00 Jonathan Gibbons : >> >> On 01/13/2017 08:59 AM, Denis Istomin wrote: >>> Fixed using Void at private method declaration. >> >> Denis, >> >> Same comment as previous review, regarding newlines and terse error >> messages. >> >> -- Jon Denis, Reviewed and pushed. Thanks, -- Jon From claes.redestad at oracle.com Wed Jan 25 10:27:07 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 25 Jan 2017 11:27:07 +0100 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: <68c9883f-ecb7-eadb-d504-6621c278a4c7@oracle.com> 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? 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 maurizio.cimadamore at oracle.com Wed Jan 25 11:29:25 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 25 Jan 2017 11:29:25 +0000 Subject: RFR: JDK-8171294: Slow compilation with long classpaths under JDK 9 In-Reply-To: <68c9883f-ecb7-eadb-d504-6621c278a4c7@oracle.com> References: <5887662B.8030702@oracle.com> <68c9883f-ecb7-eadb-d504-6621c278a4c7@oracle.com> Message-ID: <3e93b404-5521-a576-d4a7-37e548c83d61@oracle.com> 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? 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 jan.lahoda at oracle.com Wed Jan 25 12:27:28 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Jan 2017 13:27:28 +0100 Subject: RFR: JDK-8171294: Slow compilation with long classpaths under JDK 9 In-Reply-To: <3e93b404-5521-a576-d4a7-37e548c83d61@oracle.com> References: <5887662B.8030702@oracle.com> <68c9883f-ecb7-eadb-d504-6621c278a4c7@oracle.com> <3e93b404-5521-a576-d4a7-37e548c83d61@oracle.com> Message-ID: <588899B0.6030502@oracle.com> 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. 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 claes.redestad at oracle.com Wed Jan 25 12:59:23 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 25 Jan 2017 13:59:23 +0100 Subject: RFR: JDK-8171294: Slow compilation with long classpaths under JDK 9 In-Reply-To: <588899B0.6030502@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> Message-ID: <7c91a098-5124-e42f-e365-d25f0f981f94@oracle.com> 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? 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 jan.lahoda at oracle.com Wed Jan 25 13:24:27 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Jan 2017 14:24:27 +0100 Subject: RFR: JDK-8171294: Slow compilation with long classpaths under JDK 9 In-Reply-To: <7c91a098-5124-e42f-e365-d25f0f981f94@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> Message-ID: <5888A70B.3000901@oracle.com> 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. (Adding Steve on CC.) 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 claes.redestad at oracle.com Wed Jan 25 13:42:15 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 25 Jan 2017 14:42:15 +0100 Subject: RFR: JDK-8171294: Slow compilation with long classpaths under JDK 9 In-Reply-To: <5888A70B.3000901@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> Message-ID: <44e84136-1fb0-3b4d-a186-452262b2392c@oracle.com> 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 > > 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 jan.lahoda at oracle.com Wed Jan 25 17:23:33 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Jan 2017 18:23:33 +0100 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: <5888DF15.3050807@oracle.com> On 25.1.2017 14:42, 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. I've prepared a simple test here: http://cr.openjdk.java.net/~jlahoda/MultiReleaseJar.java Seems that javac is (both before and after this patch) behaving in line with what JarFileSystem is returning. AFAIK, javac is passing the multi-release property to JarFileSystem properly and is relying on JarFileSystem to handle multi-release jars. So, if a different behavior is desired, I think it would be good to have a bug filled against JarFileSystem, and have it fixed there. Thanks, Jan > > Thanks! > > /Claes > >> >> 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 jan.lahoda at oracle.com Wed Jan 25 17:59:08 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 25 Jan 2017 18:59:08 +0100 Subject: RFR: JDK-8171294: Slow compilation with long classpaths under JDK 9 In-Reply-To: <5888DF15.3050807@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> <5888DF15.3050807@oracle.com> Message-ID: <5888E76C.9000700@oracle.com> On 25.1.2017 18:23, Jan Lahoda wrote: > On 25.1.2017 14:42, 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. > > I've prepared a simple test here: > http://cr.openjdk.java.net/~jlahoda/MultiReleaseJar.java > > Seems that javac is (both before and after this patch) behaving in line > with what JarFileSystem is returning. AFAIK, javac is passing the > multi-release property to JarFileSystem properly and is relying on > JarFileSystem to handle multi-release jars. So, if a different behavior > is desired, I think it would be good to have a bug filled against > JarFileSystem, and have it fixed there. (fwiw, I can file the bug if you wish.) Jan > > Thanks, > Jan > >> >> Thanks! >> >> /Claes >> >>> >>> 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 bsrbnd at gmail.com Wed Jan 25 20:23:30 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 25 Jan 2017 21:23:30 +0100 Subject: [PATCH] 8036827: Incorrect printing of the generic method declaration Message-ID: Hi, Next is a suggestion to remove javap's redundant printing of "extends java.lang.Object" in the following example (according to JDK 8036827 description): class JDK_8036827 { public T m1(T a) { return null; } } Regards, 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 @@ -344,8 +344,7 @@ public StringBuilder visitTypeParamType(TypeParamType type, StringBuilder sb) { sb.append(type.name); String sep = " extends "; - if (type.classBound != null - && (options.verbose || !type.classBound.isObject())) { + if (type.classBound != null && !type.classBound.isObject()) { sb.append(sep); append(sb, type.classBound); sep = " & "; From henry.jen at oracle.com Wed Jan 25 21:23:51 2017 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 25 Jan 2017 13:23:51 -0800 Subject: RFR: 8172309: classpath wildcards code does not support --class-path Message-ID: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com> Hi, Please review the webrev[1], the fix is to ensure ?class-path and ?class-path= is processed correctly to expand wildcard. Changes are made in jdk repo. However, test case to verify the bug fix is in langtool repo. Cheers, Henry [1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/ [2] https://bugs.openjdk.java.net/browse/JDK-8172309 From bsrbnd at gmail.com Thu Jan 26 10:39:43 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 26 Jan 2017 11:39:43 +0100 Subject: [PATCH] 8036827: Incorrect printing of the generic method declaration In-Reply-To: References: Message-ID: Hi, 2017-01-25 21:23 GMT+01:00 B. Blaser : > > Next is a suggestion to remove javap's redundant printing of "extends > java.lang.Object" in the following example (according to JDK 8036827 > description): > > class JDK_8036827 { > public T m1(T a) { > return null; > } > } > I've also updated the existing related tests, below. 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 @@ -344,8 +344,7 @@ public StringBuilder visitTypeParamType(TypeParamType type, StringBuilder sb) { sb.append(type.name); String sep = " extends "; - if (type.classBound != null - && (options.verbose || !type.classBound.isObject())) { + if (type.classBound != null && !type.classBound.isObject()) { sb.append(sep); append(sb, type.classBound); sep = " & "; diff --git a/test/tools/javap/4870651/T4870651.java b/test/tools/javap/4870651/T4870651.java --- a/test/tools/javap/4870651/T4870651.java +++ b/test/tools/javap/4870651/T4870651.java @@ -40,7 +40,7 @@ public void run() throws IOException { verify("Test", - "class Test, " + "U extends java.lang.Comparable>", "v1(java.lang.String...)"); diff --git a/test/tools/javap/BoundsTypeVariableTest.java b/test/tools/javap/BoundsTypeVariableTest.java --- a/test/tools/javap/BoundsTypeVariableTest.java +++ b/test/tools/javap/BoundsTypeVariableTest.java @@ -49,7 +49,7 @@ srcDir.mkdirs(); File classesDir = new File("classes"); classesDir.mkdirs(); - final String expect = "public abstract U doit();"; + final String expect = "public abstract U doit();"; List contents = new ArrayList<>(); contents.add("abstract class X {"); contents.add(expect); From joe.darcy at oracle.com Thu Jan 26 20:37:12 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 26 Jan 2017 12:37:12 -0800 Subject: JDK 10 RFR of 8028544 and 8028546 Message-ID: <2f12b322-4c27-ce4e-fd0e-8e99f1e91a78@oracle.com> Hello, As part of JDK 10 ground breaking, I'm working on fixes to JDK-8028544: Add SourceVersion.RELEASE_10 JDK-8028546: Add -source 10 and -target 10 to javac Current webrev available at http://cr.openjdk.java.net/~darcy/8028546.1/ With a few exceptions, the langtools tests are all passing with these changes. I updated a few annotation processing tests from using the vanilla AbstractProcessor to the JavacTestingAbstractProcessor. The exceptions include the currently failing tests FAILED: tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java FAILED: tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java FAILED: tools/javac/file/MultiReleaseJar/MultiReleaseJarTest.java The failures seem related to the --release option. At least until the Java SE 9 API is finalized, I think it is okay for --release 9 and --release 10 to mean the same thing and refer to the in-forest state of the API. However, I haven't fully reverse-engineered how to do that. Thanks, -Joe From jonathan.gibbons at oracle.com Thu Jan 26 21:24:03 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 26 Jan 2017 13:24:03 -0800 Subject: [PATCH] 8036827: Incorrect printing of the generic method declaration In-Reply-To: References: Message-ID: <588A68F3.70801@oracle.com> Bernard, I don't think this should be changed, and I will close out the JBS issue. Without the -verbose flag, the "extends java.lang.Object" is not printed. $ ./build/linux-x86_64-normal-server-release/images/jdk/bin/javap play/src/JDK_8036827.class Compiled from "JDK_8036827.java" class JDK_8036827 { JDK_8036827(); public T m1(T); } When the -verbose flag is used, it does not seem unreasonable to print out information which is explicitly present in the class file. -- Jon On 01/26/2017 02:39 AM, B. Blaser wrote: > Hi, > > 2017-01-25 21:23 GMT+01:00 B. Blaser : >> Next is a suggestion to remove javap's redundant printing of "extends >> java.lang.Object" in the following example (according to JDK 8036827 >> description): >> >> class JDK_8036827 { >> public T m1(T a) { >> return null; >> } >> } >> > I've also updated the existing related tests, below. > > 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 > @@ -344,8 +344,7 @@ > public StringBuilder visitTypeParamType(TypeParamType > type, StringBuilder sb) { > sb.append(type.name); > String sep = " extends "; > - if (type.classBound != null > - && (options.verbose || !type.classBound.isObject())) { > + if (type.classBound != null && !type.classBound.isObject()) { > sb.append(sep); > append(sb, type.classBound); > sep = " & "; > diff --git a/test/tools/javap/4870651/T4870651.java > b/test/tools/javap/4870651/T4870651.java > --- a/test/tools/javap/4870651/T4870651.java > +++ b/test/tools/javap/4870651/T4870651.java > @@ -40,7 +40,7 @@ > > public void run() throws IOException { > verify("Test", > - "class Test + "class Test "E extends java.lang.Exception & > java.lang.Comparable, " + > "U extends java.lang.Comparable>", > "v1(java.lang.String...)"); > diff --git a/test/tools/javap/BoundsTypeVariableTest.java > b/test/tools/javap/BoundsTypeVariableTest.java > --- a/test/tools/javap/BoundsTypeVariableTest.java > +++ b/test/tools/javap/BoundsTypeVariableTest.java > @@ -49,7 +49,7 @@ > srcDir.mkdirs(); > File classesDir = new File("classes"); > classesDir.mkdirs(); > - final String expect = "public abstract java.lang.Object> U doit();"; > + final String expect = "public abstract U doit();"; > List contents = new ArrayList<>(); > contents.add("abstract class X {"); > contents.add(expect); From kumar.x.srinivasan at oracle.com Thu Jan 26 22:31:10 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 26 Jan 2017 14:31:10 -0800 Subject: RFR: 8172309: classpath wildcards code does not support --class-path In-Reply-To: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com> References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com> Message-ID: <588A78AE.9020101@oracle.com> Hi Henry, Looks ok to me. Thanks for making this change. Kumar > Hi, > > Please review the webrev[1], the fix is to ensure ?class-path and ?class-path= is processed correctly to expand wildcard. Changes are made in jdk repo. However, test case to verify the bug fix is in langtool repo. > > Cheers, > Henry > > [1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/ > [2] https://bugs.openjdk.java.net/browse/JDK-8172309 From jonathan.gibbons at oracle.com Fri Jan 27 00:09:25 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 26 Jan 2017 16:09:25 -0800 Subject: RFR: 8172309: classpath wildcards code does not support --class-path In-Reply-To: <588A78AE.9020101@oracle.com> References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com> <588A78AE.9020101@oracle.com> Message-ID: <588A8FB5.5020601@oracle.com> Henry, You've changed old test cases into new test cases, thereby eliminating the old cases, which is not so good. You should be adding new test cases, but changing old ones. -- Jon On 01/26/2017 02:31 PM, Kumar Srinivasan wrote: > > Hi Henry, > > Looks ok to me. Thanks for making this change. > > Kumar > >> Hi, >> >> Please review the webrev[1], the fix is to ensure ?class-path and >> ?class-path= is processed correctly to expand wildcard. Changes are >> made in jdk repo. However, test case to verify the bug fix is in >> langtool repo. >> >> Cheers, >> Henry >> >> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8172309 > From joe.darcy at oracle.com Fri Jan 27 00:23:33 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 26 Jan 2017 16:23:33 -0800 Subject: JDK 10 RFR of 8028544 and 8028546 In-Reply-To: <2f12b322-4c27-ce4e-fd0e-8e99f1e91a78@oracle.com> References: <2f12b322-4c27-ce4e-fd0e-8e99f1e91a78@oracle.com> Message-ID: Hello, All langtools tests should be passing now with the refined changes in http://cr.openjdk.java.net/~darcy/8028546.2/ Stuart, jdeprscan required some minor edits. As noted implicitly in the some of changes, some of the areas of the code affected on this webrev will need revision once there is distinct support for --release 9 and --release 10. Thanks, -Joe On 1/26/2017 12:37 PM, joe darcy wrote: > Hello, > > As part of JDK 10 ground breaking, I'm working on fixes to > > JDK-8028544: Add SourceVersion.RELEASE_10 > JDK-8028546: Add -source 10 and -target 10 to javac > > Current webrev available at > > http://cr.openjdk.java.net/~darcy/8028546.1/ > > With a few exceptions, the langtools tests are all passing with these > changes. I updated a few annotation processing tests from using the > vanilla AbstractProcessor to the JavacTestingAbstractProcessor. The > exceptions include the currently failing tests > > FAILED: > tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java > FAILED: tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java > FAILED: tools/javac/file/MultiReleaseJar/MultiReleaseJarTest.java > > The failures seem related to the --release option. At least until the > Java SE 9 API is finalized, I think it is okay for --release 9 and > --release 10 to mean the same thing and refer to the in-forest state > of the API. However, I haven't fully reverse-engineered how to do that. > > Thanks, > > -Joe > From jonathan.gibbons at oracle.com Fri Jan 27 00:41:43 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 26 Jan 2017 16:41:43 -0800 Subject: JDK 10 RFR of 8028544 and 8028546 In-Reply-To: References: <2f12b322-4c27-ce4e-fd0e-8e99f1e91a78@oracle.com> Message-ID: <588A9747.8020406@oracle.com> Mostly OK. test/tools/javac/file/MultiReleaseJar/MultiReleaseJarTest.java I wonder whether in this test you should be adding a test case, instead of changing 9 to 10. -- Jon On 01/26/2017 04:23 PM, joe darcy wrote: > Hello, > > All langtools tests should be passing now with the refined changes in > > http://cr.openjdk.java.net/~darcy/8028546.2/ > > Stuart, jdeprscan required some minor edits. > > As noted implicitly in the some of changes, some of the areas of the > code affected on this webrev will need revision once there is distinct > support for --release 9 and --release 10. > > Thanks, > > -Joe > > > On 1/26/2017 12:37 PM, joe darcy wrote: >> Hello, >> >> As part of JDK 10 ground breaking, I'm working on fixes to >> >> JDK-8028544: Add SourceVersion.RELEASE_10 >> JDK-8028546: Add -source 10 and -target 10 to javac >> >> Current webrev available at >> >> http://cr.openjdk.java.net/~darcy/8028546.1/ >> >> With a few exceptions, the langtools tests are all passing with these >> changes. I updated a few annotation processing tests from using the >> vanilla AbstractProcessor to the JavacTestingAbstractProcessor. The >> exceptions include the currently failing tests >> >> FAILED: >> tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java >> FAILED: tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java >> FAILED: tools/javac/file/MultiReleaseJar/MultiReleaseJarTest.java >> >> The failures seem related to the --release option. At least until the >> Java SE 9 API is finalized, I think it is okay for --release 9 and >> --release 10 to mean the same thing and refer to the in-forest state >> of the API. However, I haven't fully reverse-engineered how to do that. >> >> Thanks, >> >> -Joe >> > From joe.darcy at oracle.com Fri Jan 27 00:49:05 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 26 Jan 2017 16:49:05 -0800 Subject: JDK 10 RFR of 8028544 and 8028546 In-Reply-To: <588A9747.8020406@oracle.com> References: <2f12b322-4c27-ce4e-fd0e-8e99f1e91a78@oracle.com> <588A9747.8020406@oracle.com> Message-ID: <3961b906-825d-6036-cda7-517b09a8d7bb@oracle.com> On 1/26/2017 4:41 PM, Jonathan Gibbons wrote: > Mostly OK. > > test/tools/javac/file/MultiReleaseJar/MultiReleaseJarTest.java > I wonder whether in this test you should be adding a test case, > instead of changing 9 to 10. I just kicked off a fresh test run. I'll revisit this test once that run completes. The support for --release may be a bit odd until 9 is truly separate from 10, but we should make it as full as possible as soon as possible. Thanks, -Joe > > -- Jon > > > On 01/26/2017 04:23 PM, joe darcy wrote: >> Hello, >> >> All langtools tests should be passing now with the refined changes in >> >> http://cr.openjdk.java.net/~darcy/8028546.2/ >> >> Stuart, jdeprscan required some minor edits. >> >> As noted implicitly in the some of changes, some of the areas of the >> code affected on this webrev will need revision once there is >> distinct support for --release 9 and --release 10. >> >> Thanks, >> >> -Joe >> >> >> On 1/26/2017 12:37 PM, joe darcy wrote: >>> Hello, >>> >>> As part of JDK 10 ground breaking, I'm working on fixes to >>> >>> JDK-8028544: Add SourceVersion.RELEASE_10 >>> JDK-8028546: Add -source 10 and -target 10 to javac >>> >>> Current webrev available at >>> >>> http://cr.openjdk.java.net/~darcy/8028546.1/ >>> >>> With a few exceptions, the langtools tests are all passing with >>> these changes. I updated a few annotation processing tests from >>> using the vanilla AbstractProcessor to the >>> JavacTestingAbstractProcessor. The exceptions include the currently >>> failing tests >>> >>> FAILED: >>> tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java >>> >>> FAILED: tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java >>> FAILED: tools/javac/file/MultiReleaseJar/MultiReleaseJarTest.java >>> >>> The failures seem related to the --release option. At least until >>> the Java SE 9 API is finalized, I think it is okay for --release 9 >>> and --release 10 to mean the same thing and refer to the in-forest >>> state of the API. However, I haven't fully reverse-engineered how to >>> do that. >>> >>> Thanks, >>> >>> -Joe >>> >> > From henry.jen at oracle.com Fri Jan 27 02:01:12 2017 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 26 Jan 2017 18:01:12 -0800 Subject: RFR: 8172309: classpath wildcards code does not support --class-path In-Reply-To: <588A8FB5.5020601@oracle.com> References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com> <588A78AE.9020101@oracle.com> <588A8FB5.5020601@oracle.com> Message-ID: > On Jan 26, 2017, at 4:09 PM, Jonathan Gibbons wrote: > > Henry, > > You've changed old test cases into new test cases, thereby eliminating the old cases, which is not so good. > > You should be adding new test cases, but changing old ones. > I am not sure, I believe all wild-card cases still tested, just that we have different variety of calling -cp. Of course, it would be nice to test all cases with all 4 flavors of -cp, but I don?t think that?s necessary as I think the test coverage is the same. Anyway, I could be wrong. If you feel strong about this, I can redo it. But that may takes more time to digest what the test cases are really for. Cheers, Henry > -- Jon > > > On 01/26/2017 02:31 PM, Kumar Srinivasan wrote: >> >> Hi Henry, >> >> Looks ok to me. Thanks for making this change. >> >> Kumar >> >>> Hi, >>> >>> Please review the webrev[1], the fix is to ensure ?class-path and ?class-path= is processed correctly to expand wildcard. Changes are made in jdk repo. However, test case to verify the bug fix is in langtool repo. >>> >>> Cheers, >>> Henry >>> >>> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-8172309 >> > From joe.darcy at oracle.com Fri Jan 27 02:05:50 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 26 Jan 2017 18:05:50 -0800 Subject: JDK 10 RFR of 8028544 and 8028546 In-Reply-To: <3961b906-825d-6036-cda7-517b09a8d7bb@oracle.com> References: <2f12b322-4c27-ce4e-fd0e-8e99f1e91a78@oracle.com> <588A9747.8020406@oracle.com> <3961b906-825d-6036-cda7-517b09a8d7bb@oracle.com> Message-ID: Minor revision up at: http://cr.openjdk.java.net/~darcy/8028546.3/ Changes to MultiReleaseJarTest.java were reverted; updating the test to more extensively cover 10 is left for future work. (I'm not familiar with the logistics of testng tests so it wasn't trivial for me to add support for testing 10 as well as 9; it may be trivial for someone familiar with testng.) Small diff added to ProfileOptionTest: --- a/test/tools/javac/profiles/ProfileOptionTest.java Wed Jan 25 22:32:52 2017 +0000 +++ b/test/tools/javac/profiles/ProfileOptionTest.java Thu Jan 26 18:04:56 2017 -0800 @@ -148,6 +148,7 @@ error("unexpected exception from compiler: " + ise); break; case JDK1_9: + case JDK1_10: if (p == Profile.DEFAULT) break; if (ise == null) With these changes, all the langtools tests pass and I verified the java/util/jar tests pass too. Thanks, -Joe On 1/26/2017 4:49 PM, joe darcy wrote: > > On 1/26/2017 4:41 PM, Jonathan Gibbons wrote: >> Mostly OK. >> >> test/tools/javac/file/MultiReleaseJar/MultiReleaseJarTest.java >> I wonder whether in this test you should be adding a test case, >> instead of changing 9 to 10. > > I just kicked off a fresh test run. I'll revisit this test once that > run completes. > > The support for --release may be a bit odd until 9 is truly separate > from 10, but we should make it as full as possible as soon as possible. > > Thanks, > > -Joe > >> >> -- Jon >> >> >> On 01/26/2017 04:23 PM, joe darcy wrote: >>> Hello, >>> >>> All langtools tests should be passing now with the refined changes in >>> >>> http://cr.openjdk.java.net/~darcy/8028546.2/ >>> >>> Stuart, jdeprscan required some minor edits. >>> >>> As noted implicitly in the some of changes, some of the areas of the >>> code affected on this webrev will need revision once there is >>> distinct support for --release 9 and --release 10. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 1/26/2017 12:37 PM, joe darcy wrote: >>>> Hello, >>>> >>>> As part of JDK 10 ground breaking, I'm working on fixes to >>>> >>>> JDK-8028544: Add SourceVersion.RELEASE_10 >>>> JDK-8028546: Add -source 10 and -target 10 to javac >>>> >>>> Current webrev available at >>>> >>>> http://cr.openjdk.java.net/~darcy/8028546.1/ >>>> >>>> With a few exceptions, the langtools tests are all passing with >>>> these changes. I updated a few annotation processing tests from >>>> using the vanilla AbstractProcessor to the >>>> JavacTestingAbstractProcessor. The exceptions include the currently >>>> failing tests >>>> >>>> FAILED: >>>> tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java >>>> >>>> FAILED: tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java >>>> FAILED: tools/javac/file/MultiReleaseJar/MultiReleaseJarTest.java >>>> >>>> The failures seem related to the --release option. At least until >>>> the Java SE 9 API is finalized, I think it is okay for --release 9 >>>> and --release 10 to mean the same thing and refer to the in-forest >>>> state of the API. However, I haven't fully reverse-engineered how >>>> to do that. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>> >> > From henry.jen at oracle.com Fri Jan 27 21:12:23 2017 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 27 Jan 2017 13:12:23 -0800 Subject: RFR: 8172309: classpath wildcards code does not support --class-path In-Reply-To: References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com> <588A78AE.9020101@oracle.com> <588A8FB5.5020601@oracle.com> Message-ID: <30EF55B3-B321-4488-BFAD-1993E0F31A6C@oracle.com> How about following patch instead for langtools repo? diff -r ef142ac9824e test/tools/javac/Paths/wcMineField.sh --- a/test/tools/javac/Paths/wcMineField.sh Thu Jan 26 16:53:56 2017 -0800 +++ b/test/tools/javac/Paths/wcMineField.sh Fri Jan 27 13:10:12 2017 -0800 @@ -26,7 +26,7 @@ # # @test # @summary Test classpath wildcards for javac and java -classpath option. -# @bug 6268383 +# @bug 6268383 8172309 # @run shell/timeout=600 wcMineField.sh # To run this test manually, simply do ./wcMineField.sh @@ -186,6 +186,8 @@ Failure "$javac" ${TESTTOOLVMOPTS} -classpath "GooJar/*${PS}." Main1.java Success "$javac" ${TESTTOOLVMOPTS} -cp "GooJar/SubDir/*" Main1.java Success "$javac" ${TESTTOOLVMOPTS} -classpath "GooJar/SubDir/*" Main1.java +Success "$javac" ${TESTTOOLVMOPTS} --class-path "GooJar/SubDir/*" Main1.java +Success "$javac" ${TESTTOOLVMOPTS} --class-path="GooJar/SubDir/*" Main1.java #Same with launcher. Should not load jar in subdirectories unless specified Failure "$java" ${TESTVMOPTS} -classpath "GooJar/*${PS}." Main1 Success "$java" ${TESTVMOPTS} -classpath "GooJar/SubDir/*${PS}." Main1 Cheers, Henry > On Jan 26, 2017, at 6:01 PM, Henry Jen wrote: > >> On Jan 26, 2017, at 4:09 PM, Jonathan Gibbons wrote: >> >> Henry, >> >> You've changed old test cases into new test cases, thereby eliminating the old cases, which is not so good. >> >> You should be adding new test cases, but changing old ones. >> > > I am not sure, I believe all wild-card cases still tested, just that we have different variety of calling -cp. Of course, it would be nice to test all cases with all 4 flavors of -cp, but I don?t think that?s necessary as I think the test coverage is the same. > > Anyway, I could be wrong. If you feel strong about this, I can redo it. But that may takes more time to digest what the test cases are really for. > > Cheers, > Henry > > >> -- Jon >> >> >> On 01/26/2017 02:31 PM, Kumar Srinivasan wrote: >>> >>> Hi Henry, >>> >>> Looks ok to me. Thanks for making this change. >>> >>> Kumar >>> >>>> Hi, >>>> >>>> Please review the webrev[1], the fix is to ensure ?class-path and ?class-path= is processed correctly to expand wildcard. Changes are made in jdk repo. However, test case to verify the bug fix is in langtool repo. >>>> >>>> Cheers, >>>> Henry >>>> >>>> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/ >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8172309 >>> >> > From bsrbnd at gmail.com Fri Jan 27 22:05:46 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 27 Jan 2017 23:05:46 +0100 Subject: [PATCH] 8036827: Incorrect printing of the generic method declaration In-Reply-To: <588A68F3.70801@oracle.com> References: <588A68F3.70801@oracle.com> Message-ID: Thanks for your answer. It seems reasonable to print it and compliant with the comments you provided in JDK 7031005. I think there's probably a slight inconsistency similar to JDK 7031005, but for classes. With -verbose, we have: 1) Info from super_class: $ more JDK_8036827.java class JDK_8036827 {} $ javap -v JDK_8036827.class Compiled from "JDK_8036827.java" class JDK_8036827 2) Info from class signature: $ more JDK_8036827.java class JDK_8036827 {} $ javap -v JDK_8036827.class Compiled from "JDK_8036827.java" class JDK_8036827 extends java.lang.Object What's the correct expectation? Should "extends java.lang.Object" be present in the first example as this information is present in the class file? This would be coherent with your first comment in JDK 7031005, but I don't know if something has changed since you wrote it. Bernard 2017-01-26 22:24 GMT+01:00 Jonathan Gibbons : > Bernard, > > I don't think this should be changed, and I will close out the JBS issue. > > Without the -verbose flag, the "extends java.lang.Object" is not printed. > > $ ./build/linux-x86_64-normal-server-release/images/jdk/bin/javap > play/src/JDK_8036827.class > Compiled from "JDK_8036827.java" > class JDK_8036827 { > JDK_8036827(); > public T m1(T); > } > > When the -verbose flag is used, it does not seem unreasonable to print out > information which is explicitly present in the class file. > > -- Jon > > > > On 01/26/2017 02:39 AM, B. Blaser wrote: >> >> Hi, >> >> 2017-01-25 21:23 GMT+01:00 B. Blaser : >>> >>> Next is a suggestion to remove javap's redundant printing of "extends >>> java.lang.Object" in the following example (according to JDK 8036827 >>> description): >>> >>> class JDK_8036827 { >>> public T m1(T a) { >>> return null; >>> } >>> } >>> >> I've also updated the existing related tests, below. >> >> 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 >> @@ -344,8 +344,7 @@ >> public StringBuilder visitTypeParamType(TypeParamType >> type, StringBuilder sb) { >> sb.append(type.name); >> String sep = " extends "; >> - if (type.classBound != null >> - && (options.verbose || >> !type.classBound.isObject())) { >> + if (type.classBound != null && >> !type.classBound.isObject()) { >> sb.append(sep); >> append(sb, type.classBound); >> sep = " & "; >> diff --git a/test/tools/javap/4870651/T4870651.java >> b/test/tools/javap/4870651/T4870651.java >> --- a/test/tools/javap/4870651/T4870651.java >> +++ b/test/tools/javap/4870651/T4870651.java >> @@ -40,7 +40,7 @@ >> >> public void run() throws IOException { >> verify("Test", >> - "class Test> + "class Test> "E extends java.lang.Exception & >> java.lang.Comparable, " + >> "U extends java.lang.Comparable>", >> "v1(java.lang.String...)"); >> diff --git a/test/tools/javap/BoundsTypeVariableTest.java >> b/test/tools/javap/BoundsTypeVariableTest.java >> --- a/test/tools/javap/BoundsTypeVariableTest.java >> +++ b/test/tools/javap/BoundsTypeVariableTest.java >> @@ -49,7 +49,7 @@ >> srcDir.mkdirs(); >> File classesDir = new File("classes"); >> classesDir.mkdirs(); >> - final String expect = "public abstract > java.lang.Object> U doit();"; >> + final String expect = "public abstract U doit();"; >> List contents = new ArrayList<>(); >> contents.add("abstract class X {"); >> contents.add(expect); > > From bsrbnd at gmail.com Sat Jan 28 18:26:10 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 28 Jan 2017 19:26:10 +0100 Subject: [PATCH] 8036827: Incorrect printing of the generic method declaration In-Reply-To: References: <588A68F3.70801@oracle.com> Message-ID: Jonathan, 2017-01-27 23:05 GMT+01:00 B. Blaser : > Thanks for your answer. > It seems reasonable to print it and compliant with the comments you > provided in JDK 7031005. > > I think there's probably a slight inconsistency similar to JDK > 7031005, but for classes. > With -verbose, we have: > > 1) Info from super_class: > > $ more JDK_8036827.java > class JDK_8036827 {} > > $ javap -v JDK_8036827.class > Compiled from "JDK_8036827.java" > class JDK_8036827 > > 2) Info from class signature: > > $ more JDK_8036827.java > class JDK_8036827 {} > > $ javap -v JDK_8036827.class > Compiled from "JDK_8036827.java" > class JDK_8036827 extends java.lang.Object > > What's the correct expectation? > > Should "extends java.lang.Object" be present in the first example as > this information is present in the class file? If so, I suggest the following fix along with the associate test updated to check the -verbose behavior. 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 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2007, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2007, 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 @@ -205,7 +205,7 @@ // use info from class file header if (classFile.isClass() && classFile.super_class != 0 ) { String sn = getJavaSuperclassName(cf); - if (!sn.equals("java.lang.Object")) { + if (options.verbose || !sn.equals("java.lang.Object")) { print(" extends "); print(sn); } diff --git a/test/tools/javap/TestSuperclass.java b/test/tools/javap/TestSuperclass.java --- a/test/tools/javap/TestSuperclass.java +++ b/test/tools/javap/TestSuperclass.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2011, 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 @@ -53,12 +53,14 @@ } enum GenericKind { - NO(""), - YES(""); - GenericKind(String typarams) { + NO("", ""), + YES("", ""); + GenericKind(String typarams, String verbose) { this.typarams = typarams; + this.verbose = verbose; } final String typarams; + final String verbose; } enum SuperKind { @@ -73,6 +75,9 @@ String decl(ClassKind ck) { return (name == null) ? "" : ck.keyword + " " + name + " { }"; } + String verbose(ClassKind ck) { + return ck == ClassKind.CLASS && name == null ? "extends java.lang.Object" : extend(); + } final String name; } @@ -117,28 +122,41 @@ throw new Error("compilation failed"); File testClass = new File(testDir, "Test.class"); - String out = javap(testClass); + + System.err.print("normal: "); + String out = javap(testClass.getPath()); // Extract class sig from first line of Java source String expect = js.source.replaceAll("(?s)^(.* Test[^{]+?) *\\{.*", "$1"); // Extract class sig from line from javap output String found = out.replaceAll("(?s).*\n(.* Test[^{]+?) *\\{.*", "$1"); + System.err.println(found); checkEqual("class signature", expect, found); + System.err.print("verbose: "); + out = javap("-v", testClass.getPath()); + + String verbose = ck.keyword + " Test" + gk.verbose + + (sk.verbose(ck).isEmpty() ? "" : " " + sk.verbose(ck)); + + if (out.contains(verbose)) + System.err.println(verbose); + else + checkEqual("class signature", verbose, out); + + System.err.println(); + return errors; } - String javap(File file) { + String javap(String... args) { StringWriter sw = new StringWriter(); PrintWriter pw = new PrintWriter(sw); - String[] args = { file.getPath() }; int rc = com.sun.tools.javap.Main.run(args, pw); pw.close(); String out = sw.toString(); - if (!out.isEmpty()) - System.err.println(out); if (rc != 0) throw new Error("javap failed: rc=" + rc); return out; > 2017-01-26 22:24 GMT+01:00 Jonathan Gibbons : >> Bernard, >> >> I don't think this should be changed, and I will close out the JBS issue. >> >> Without the -verbose flag, the "extends java.lang.Object" is not printed. >> >> $ ./build/linux-x86_64-normal-server-release/images/jdk/bin/javap >> play/src/JDK_8036827.class >> Compiled from "JDK_8036827.java" >> class JDK_8036827 { >> JDK_8036827(); >> public T m1(T); >> } >> >> When the -verbose flag is used, it does not seem unreasonable to print out >> information which is explicitly present in the class file. >> >> -- Jon From joe.darcy at oracle.com Sat Jan 28 21:39:26 2017 From: joe.darcy at oracle.com (joe darcy) Date: Sat, 28 Jan 2017 13:39:26 -0800 Subject: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules Message-ID: <827c07f6-3e3d-7ca9-aa54-b7dbc9efe827@oracle.com> Hello, Please review the straightforward fix to address: JDK-8173609: Elements.printElements needs to support modules http://cr.openjdk.java.net/~darcy/8173609.0/ Once additional information about modules is available (JDK-8172810: ModuleElement should declare and provide appropriate modifiers), the printing processor should be updated to expose that information. Admittedly this changeset would be better with some regression testing. Thanks, -Joe From forax at univ-mlv.fr Sun Jan 29 11:21:59 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 29 Jan 2017 12:21:59 +0100 (CET) Subject: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules In-Reply-To: <827c07f6-3e3d-7ca9-aa54-b7dbc9efe827@oracle.com> References: <827c07f6-3e3d-7ca9-aa54-b7dbc9efe827@oracle.com> Message-ID: <139379907.2211874.1485688919540.JavaMail.zimbra@u-pem.fr> Hi Joe, i believe that all non public methods you have added can be declared private, and printNameableList can use a stream and a collector private void printNameableList(List nameables) { writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(", ")); } cheers, R?mi ----- Mail original ----- > De: "joe darcy" > ?: compiler-dev at openjdk.java.net > Envoy?: Samedi 28 Janvier 2017 22:39:26 > Objet: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules > Hello, > > Please review the straightforward fix to address: > > JDK-8173609: Elements.printElements needs to support modules > http://cr.openjdk.java.net/~darcy/8173609.0/ > > Once additional information about modules is available (JDK-8172810: > ModuleElement should declare and provide appropriate modifiers), the > printing processor should be updated to expose that information. > > Admittedly this changeset would be better with some regression testing. > > Thanks, > > -Joe From joe.darcy at oracle.com Sun Jan 29 20:55:28 2017 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 29 Jan 2017 12:55:28 -0800 Subject: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules In-Reply-To: <139379907.2211874.1485688919540.JavaMail.zimbra@u-pem.fr> References: <827c07f6-3e3d-7ca9-aa54-b7dbc9efe827@oracle.com> <139379907.2211874.1485688919540.JavaMail.zimbra@u-pem.fr> Message-ID: <05a7789a-17f9-a45d-f87f-d6707a02305a@oracle.com> Hi Remi, On 1/29/2017 3:21 AM, Remi Forax wrote: > Hi Joe, > i believe that all non public methods you have added can be declared private, Good point; I'll make that change before pushing. > and printNameableList can use a stream and a collector > > private void printNameableList(List nameables) { > writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(", ")); I thought of using that style instead and changed some core reflection code to use streams and collectors earlier in 9 (JDK-8162817: Annotation toString output not reusable for source input). I'll let Jon or Jan weigh in on which style is preferred for javac. Thanks, -Joe > } > > cheers, > R?mi > > ----- Mail original ----- >> De: "joe darcy" >> ?: compiler-dev at openjdk.java.net >> Envoy?: Samedi 28 Janvier 2017 22:39:26 >> Objet: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules >> Hello, >> >> Please review the straightforward fix to address: >> >> JDK-8173609: Elements.printElements needs to support modules >> http://cr.openjdk.java.net/~darcy/8173609.0/ >> >> Once additional information about modules is available (JDK-8172810: >> ModuleElement should declare and provide appropriate modifiers), the >> printing processor should be updated to expose that information. >> >> Admittedly this changeset would be better with some regression testing. >> >> Thanks, >> >> -Joe From istomin.den at gmail.com Mon Jan 30 10:36:40 2017 From: istomin.den at gmail.com (Denis Istomin) Date: Mon, 30 Jan 2017 15:36:40 +0500 Subject: [Patch] Improve javap output -XDdetails:stackMaps Message-ID: Hi, Made patch that improves javap output with parameters "-c -XDdetails:stackMaps": 1. Add more information about frame: 1.1. frame_type 1.2. offset information 1.3. overall output of frame (there are unit-test that shows overall output of javap) 2. Refactor StackMapWriter class ? move inner classes into separate files. Some classes become public in different package. Encapsulation of other classes achived by "package-private scope level". 3. Rewrite StackMapTableVisitor (previous StackMapBuilder) 4. Other refactorings such as "Extract Method". 5. Also kind of fix of 8034066 -- Denis Istomin -------------- next part -------------- # HG changeset patch # User istomin # Date 1485768592 -18000 # Mon Jan 30 14:29:52 2017 +0500 # Branch XDdetails-stackMaps # Node ID 2bfca6302caaefde824772dff1ac6cb2409c1174 # Parent 37c0e34e835cd9722d4d0bb77288b080c66977a6 Improve javap output -XDdetails:stackMaps diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/InitialVerificationTypeInfo.java b/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/InitialVerificationTypeInfo.java new file mode 100644 --- /dev/null +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/InitialVerificationTypeInfo.java @@ -0,0 +1,44 @@ +/* + * Copyright (c) 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +package com.sun.tools.javap.StackMap; + +import com.sun.tools.classfile.StackMapTable_attribute.verification_type_info; + +/** + * Initial locals of StackFrame. + */ +class InitialVerificationTypeInfo extends verification_type_info { + public InitialVerificationTypeInfo(String text) { + super(-1); + this.text = text; + } + + public String getText(){ + return text; + } + + private String text; +} diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/StackMap.java b/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/StackMap.java new file mode 100644 --- /dev/null +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/StackMap.java @@ -0,0 +1,61 @@ +/* + * Copyright (c) 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +package com.sun.tools.javap.StackMap; + +import com.sun.tools.classfile.StackMapTable_attribute.verification_type_info; + +/** + * StackMap data to print. + */ +public class StackMap { + public StackMap(StackMap stackmap, Integer type, Integer offset) { + this.type = type; + this.offset = offset; + this.locals = stackmap.locals; + this.stack = stackmap.stack; + } + + public StackMap(Integer type, Integer offset, verification_type_info[] locals, verification_type_info[] stack) { + this.type = type; + this.offset = offset; + this.locals = locals; + this.stack = stack; + } + + public StackMap(Integer type, Integer offset, verification_type_info[] locals) { + this.type = type; + this.offset = offset; + this.locals = locals; + this.stack = empty; + } + + public final verification_type_info[] locals; + public final verification_type_info[] stack; + public final int offset; + public final int type; + + private final verification_type_info[] empty = { }; +} diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/StackMapBuilder.java b/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/StackMapBuilder.java new file mode 100644 --- /dev/null +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/StackMapBuilder.java @@ -0,0 +1,110 @@ +/* + * Copyright (c) 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +package com.sun.tools.javap.StackMap; + +import com.sun.tools.classfile.AccessFlags; +import com.sun.tools.classfile.ClassFile; +import com.sun.tools.classfile.ConstantPool; +import com.sun.tools.classfile.ConstantPoolException; +import com.sun.tools.classfile.Descriptor; +import com.sun.tools.classfile.Descriptor.InvalidDescriptor; +import com.sun.tools.classfile.Method; +import com.sun.tools.classfile.StackMapTable_attribute; +import com.sun.tools.classfile.StackMapTable_attribute.verification_type_info; + +import java.util.HashMap; +import java.util.Map; + +/** + * Builds HashMap with opcode as a key and stackMap as a value. + */ +public class StackMapBuilder { + + public StackMapBuilder(StackMapTable_attribute attr, Method method, ClassFile classFile) { + this.attr = attr; + this.method = method; + this.classFile = classFile; + } + + public Map buildHashMap() { + verification_type_info[] initialLocals = getInitialLocals(); + if (initialLocals == null) + return null; + + return buildHashMap(initialLocals); + } + + private verification_type_info[] getInitialLocals() { + if (attr == null) { + return null; + } + + Descriptor d = method.descriptor; + String[] args; + try { + ConstantPool cp = classFile.constant_pool; + String argString = d.getParameterTypes(cp); + args = argString.substring(1, argString.length() - 1).split("[, ]+"); + } catch (ConstantPoolException | InvalidDescriptor e) { + return null; + } + boolean isStatic = method.access_flags.is(AccessFlags.ACC_STATIC); + + verification_type_info[] initialLocals = new verification_type_info[(isStatic ? 0 : 1) + args.length]; + if (!isStatic) + initialLocals[0] = new InitialVerificationTypeInfo("this"); + for (int i = 0; i < args.length; i++) { + initialLocals[(isStatic ? 0 : 1) + i] = + new InitialVerificationTypeInfo(args[i].replace(".", "/")); + } + + return initialLocals; + } + + private HashMap buildHashMap(verification_type_info[] initialLocals){ + // using -1 as the pc for the initial frame effectively compensates for + // the difference in behavior for the first stack map frame (where the + // pc offset is just offset_delta) compared to subsequent frames (where + // the pc offset is always offset_delta+1). + int pc = -1; + StackMap stackMap = new StackMap(-1, -1, initialLocals); + + StackMapTableVisitor builder = new StackMapTableVisitor(); + + HashMap map = new HashMap<>();; + for (int i = 0; i < attr.entries.length; i++) { + stackMap = attr.entries[i].accept(builder, stackMap); + pc += stackMap.offset + 1; + map.put(pc, stackMap); + } + + return map; + } + + private StackMapTable_attribute attr; + private ClassFile classFile; + private Method method; +} diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/StackMapStringsUtils.java b/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/StackMapStringsUtils.java new file mode 100644 --- /dev/null +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/StackMapStringsUtils.java @@ -0,0 +1,127 @@ +/* + * Copyright (c) 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +package com.sun.tools.javap.StackMap; + +import com.sun.tools.classfile.ConstantPool; +import com.sun.tools.classfile.ConstantPoolException; +import com.sun.tools.classfile.StackMapTable_attribute.Object_variable_info; +import com.sun.tools.classfile.StackMapTable_attribute.Uninitialized_variable_info; +import com.sun.tools.classfile.StackMapTable_attribute.verification_type_info; + +import static com.sun.tools.classfile.StackMapTable_attribute.verification_type_info.ITEM_Double; +import static com.sun.tools.classfile.StackMapTable_attribute.verification_type_info.ITEM_Float; +import static com.sun.tools.classfile.StackMapTable_attribute.verification_type_info.ITEM_Integer; +import static com.sun.tools.classfile.StackMapTable_attribute.verification_type_info.ITEM_Long; +import static com.sun.tools.classfile.StackMapTable_attribute.verification_type_info.ITEM_Null; +import static com.sun.tools.classfile.StackMapTable_attribute.verification_type_info.ITEM_Object; +import static com.sun.tools.classfile.StackMapTable_attribute.verification_type_info.ITEM_Top; +import static com.sun.tools.classfile.StackMapTable_attribute.verification_type_info.ITEM_Uninitialized; +import static com.sun.tools.classfile.StackMapTable_attribute.verification_type_info.ITEM_UninitializedThis; + +/** + * User-friendly strings. + */ +public final class StackMapStringsUtils { + + public static final String getTypeToPrint(StackMap stackMap){ + int type = stackMap.type; + + if (type <= 63) + return "same_frame /* 0-63 */"; + else if (type <= 127) + return "same_locals_1_stack_item_frame /* 64-127 */"; + else if (type <= 246) + return "unknown frame_type " + type; + else if (type == 247) + return "same_locals_1_stack_item_frame_extended /* 247 */"; + else if (type <= 250) + return "chop_frame /* 248-250 */"; + else if (type == 251) + return "same_frame_extended /* 251 */"; + else if (type <= 254) + return "append_frame /* 252-254 */"; + else + return "full_frame /* 255 */"; + } + + public static final String getStringToPrint(verification_type_info entry, ConstantPool cp) { + String res = ""; + + if (entry == null) { + res = "ERROR"; + return res; + } + + switch (entry.tag) { + case -1: + res = ((InitialVerificationTypeInfo) entry).getText() + " /* init */"; + break; + + case ITEM_Top: + res = "top /* 0 */"; + break; + + case ITEM_Integer: + res = "int /* 1 */"; + break; + + case ITEM_Float: + res = "float /* 2 */"; + break; + + case ITEM_Double: + res = "double /* 3 */"; + break; + + case ITEM_Long: + res = "long /* 4 */"; + break; + + case ITEM_Null: + res = "null /* 5 */"; + break; + + case ITEM_UninitializedThis: + res = "uninit_this /* 6 */"; + break; + + case ITEM_Object: + try { + ConstantPool.CONSTANT_Class_info class_info = cp.getClassInfo(((Object_variable_info) entry).cpool_index); + res = "object " + cp.getUTF8Value(class_info.name_index) + " /* 7 */"; + } catch (ConstantPoolException e) { + res = "??"; + } + break; + + case ITEM_Uninitialized: + res = "uninit " + ((Object)((Uninitialized_variable_info) entry).offset).toString() + " /* 8 */"; + break; + } + + return res; + } +} diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/StackMapTableVisitor.java b/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/StackMapTableVisitor.java new file mode 100644 --- /dev/null +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMap/StackMapTableVisitor.java @@ -0,0 +1,85 @@ +/* + * Copyright (c) 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +package com.sun.tools.javap.StackMap; + +import com.sun.tools.classfile.StackMapTable_attribute; +import com.sun.tools.classfile.StackMapTable_attribute.append_frame; +import com.sun.tools.classfile.StackMapTable_attribute.chop_frame; +import com.sun.tools.classfile.StackMapTable_attribute.full_frame; +import com.sun.tools.classfile.StackMapTable_attribute.same_frame; +import com.sun.tools.classfile.StackMapTable_attribute.same_frame_extended; +import com.sun.tools.classfile.StackMapTable_attribute.same_locals_1_stack_item_frame; +import com.sun.tools.classfile.StackMapTable_attribute.same_locals_1_stack_item_frame_extended; +import com.sun.tools.classfile.StackMapTable_attribute.verification_type_info; + +import java.util.Arrays; + +/** + * Generates new StackMap to display, based on previous generated StackMap. + */ +class StackMapTableVisitor + implements StackMapTable_attribute.stack_map_frame.Visitor { + + public StackMap visit_same_frame(same_frame frame, StackMap prev) { + assert(prev != null); + return new StackMap(prev, frame.frame_type, frame.getOffsetDelta()); + } + + public StackMap visit_same_frame_extended(same_frame_extended frame, StackMap prev) { + assert(prev != null); + return new StackMap(prev, frame.frame_type, frame.getOffsetDelta()); + } + + public StackMap visit_same_locals_1_stack_item_frame(same_locals_1_stack_item_frame frame, StackMap prev) { + assert(prev != null); + return new StackMap(frame.frame_type, frame.getOffsetDelta(), prev.locals, frame.stack); + } + + public StackMap visit_same_locals_1_stack_item_frame_extended(same_locals_1_stack_item_frame_extended frame, StackMap prev) { + assert(prev != null); + return new StackMap(frame.frame_type, frame.getOffsetDelta(), prev.locals, frame.stack); + } + + public StackMap visit_chop_frame(chop_frame frame, StackMap prev) { + assert(prev != null); + int k = 251 - frame.frame_type; + verification_type_info[] new_locals = Arrays.copyOf(prev.locals, prev.locals.length - k); + return new StackMap(frame.frame_type, frame.getOffsetDelta(), new_locals); + } + + public StackMap visit_append_frame(append_frame frame, StackMap prev) { + assert(prev != null); + verification_type_info[] new_locals = new verification_type_info[prev.locals.length + frame.locals.length]; + System.arraycopy(prev.locals, 0, new_locals, 0, prev.locals.length); + System.arraycopy(frame.locals, 0, new_locals, prev.locals.length, frame.locals.length); + + return new StackMap(frame.frame_type, frame.getOffsetDelta(), new_locals); + } + + public StackMap visit_full_frame(full_frame frame, StackMap prev) { + return new StackMap(frame.frame_type, frame.getOffsetDelta(), frame.locals, frame.stack); + } +} diff --git a/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMapWriter.java b/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMapWriter.java --- a/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMapWriter.java +++ b/src/jdk.jdeps/share/classes/com/sun/tools/javap/StackMapWriter.java @@ -25,23 +25,20 @@ package com.sun.tools.javap; -import java.util.Arrays; -import java.util.HashMap; -import java.util.Map; - -import com.sun.tools.classfile.AccessFlags; import com.sun.tools.classfile.Attribute; import com.sun.tools.classfile.Code_attribute; import com.sun.tools.classfile.ConstantPool; -import com.sun.tools.classfile.ConstantPoolException; -import com.sun.tools.classfile.Descriptor; -import com.sun.tools.classfile.Descriptor.InvalidDescriptor; import com.sun.tools.classfile.Instruction; -import com.sun.tools.classfile.Method; import com.sun.tools.classfile.StackMapTable_attribute; -import com.sun.tools.classfile.StackMapTable_attribute.*; +import com.sun.tools.classfile.StackMapTable_attribute.verification_type_info; +import com.sun.tools.javap.StackMap.StackMap; +import com.sun.tools.javap.StackMap.StackMapBuilder; +import com.sun.tools.javap.StackMap.StackMapStringsUtils; -import static com.sun.tools.classfile.StackMapTable_attribute.verification_type_info.*; +import java.util.Arrays; +import java.util.List; +import java.util.Map; +import java.util.stream.Collectors; /** * Annotate instructions with stack map. @@ -65,49 +62,17 @@ classWriter = ClassWriter.instance(context); } + /** + * Reset mapping of Instruction offset to StakMapFrame. + * @param attr Code attribute to parse. + */ public void reset(Code_attribute attr) { - setStackMap((StackMapTable_attribute) attr.attributes.get(Attribute.StackMapTable)); - } - - void setStackMap(StackMapTable_attribute attr) { - if (attr == null) { - map = null; - return; - } + StackMapBuilder stackMapBuilder = new StackMapBuilder( + (StackMapTable_attribute) attr.attributes.get(Attribute.StackMapTable), + classWriter.getMethod(), + classWriter.getClassFile()); - Method m = classWriter.getMethod(); - Descriptor d = m.descriptor; - String[] args; - try { - ConstantPool cp = classWriter.getClassFile().constant_pool; - String argString = d.getParameterTypes(cp); - args = argString.substring(1, argString.length() - 1).split("[, ]+"); - } catch (ConstantPoolException | InvalidDescriptor e) { - return; - } - boolean isStatic = m.access_flags.is(AccessFlags.ACC_STATIC); - - verification_type_info[] initialLocals = new verification_type_info[(isStatic ? 0 : 1) + args.length]; - if (!isStatic) - initialLocals[0] = new CustomVerificationTypeInfo("this"); - for (int i = 0; i < args.length; i++) { - initialLocals[(isStatic ? 0 : 1) + i] = - new CustomVerificationTypeInfo(args[i].replace(".", "/")); - } - - map = new HashMap<>(); - StackMapBuilder builder = new StackMapBuilder(); - - // using -1 as the pc for the initial frame effectively compensates for - // the difference in behavior for the first stack map frame (where the - // pc offset is just offset_delta) compared to subsequent frames (where - // the pc offset is always offset_delta+1). - int pc = -1; - - map.put(pc, new StackMap(initialLocals, empty)); - - for (int i = 0; i < attr.entries.length; i++) - pc = attr.entries[i].accept(builder, pc); + map = stackMapBuilder.buildHashMap(); } public void writeInitialDetails() { @@ -123,167 +88,37 @@ return; StackMap m = map.get(pc); - if (m != null) { - print("StackMap locals: ", m.locals); - print("StackMap stack: ", m.stack); + if (m == null) { + return; } + indent(3); + println("[StackMap]"); + print("type: ", StackMapStringsUtils.getTypeToPrint(m)); + if (m.locals != null && m.locals.length > 0) + print("locals: ", m.locals); + if (m.stack != null && m.stack.length > 0) + print("stack: ", m.stack); + print("offset_delta: " + m.offset + ", offset_total: ", pc); + indent(-3); } void print(String label, verification_type_info[] entries) { print(label); - for (int i = 0; i < entries.length; i++) { - print(" "); - print(entries[i]); - } + ConstantPool cp = classWriter.getClassFile().constant_pool; + String strToPrint = Arrays.stream(entries) + .map(x -> StackMapStringsUtils.getStringToPrint(x, cp)) + .collect(Collectors.joining(System.lineSeparator() + " ")); + print(strToPrint); println(); } - void print(verification_type_info entry) { - if (entry == null) { - print("ERROR"); - return; - } - - switch (entry.tag) { - case -1: - print(((CustomVerificationTypeInfo) entry).text); - break; - - case ITEM_Top: - print("top"); - break; - - case ITEM_Integer: - print("int"); - break; - - case ITEM_Float: - print("float"); - break; - - case ITEM_Long: - print("long"); - break; - - case ITEM_Double: - print("double"); - break; - - case ITEM_Null: - print("null"); - break; - - case ITEM_UninitializedThis: - print("uninit_this"); - break; - - case ITEM_Object: - try { - ConstantPool cp = classWriter.getClassFile().constant_pool; - ConstantPool.CONSTANT_Class_info class_info = cp.getClassInfo(((Object_variable_info) entry).cpool_index); - print(cp.getUTF8Value(class_info.name_index)); - } catch (ConstantPoolException e) { - print("??"); - } - break; - - case ITEM_Uninitialized: - print(((Uninitialized_variable_info) entry).offset); - break; - } - + void print(String label, Object entry) { + print(label); + print(entry); + println(); } private Map map; private ClassWriter classWriter; - - class StackMapBuilder - implements StackMapTable_attribute.stack_map_frame.Visitor { - - public Integer visit_same_frame(same_frame frame, Integer pc) { - int new_pc = pc + frame.getOffsetDelta() + 1; - StackMap m = map.get(pc); - assert (m != null); - map.put(new_pc, m); - return new_pc; - } - - public Integer visit_same_locals_1_stack_item_frame(same_locals_1_stack_item_frame frame, Integer pc) { - int new_pc = pc + frame.getOffsetDelta() + 1; - StackMap prev = map.get(pc); - assert (prev != null); - StackMap m = new StackMap(prev.locals, frame.stack); - map.put(new_pc, m); - return new_pc; - } - - public Integer visit_same_locals_1_stack_item_frame_extended(same_locals_1_stack_item_frame_extended frame, Integer pc) { - int new_pc = pc + frame.getOffsetDelta() + 1; - StackMap prev = map.get(pc); - assert (prev != null); - StackMap m = new StackMap(prev.locals, frame.stack); - map.put(new_pc, m); - return new_pc; - } - - public Integer visit_chop_frame(chop_frame frame, Integer pc) { - int new_pc = pc + frame.getOffsetDelta() + 1; - StackMap prev = map.get(pc); - assert (prev != null); - int k = 251 - frame.frame_type; - verification_type_info[] new_locals = Arrays.copyOf(prev.locals, prev.locals.length - k); - StackMap m = new StackMap(new_locals, empty); - map.put(new_pc, m); - return new_pc; - } - - public Integer visit_same_frame_extended(same_frame_extended frame, Integer pc) { - int new_pc = pc + frame.getOffsetDelta(); - StackMap m = map.get(pc); - assert (m != null); - map.put(new_pc, m); - return new_pc; - } - - public Integer visit_append_frame(append_frame frame, Integer pc) { - int new_pc = pc + frame.getOffsetDelta() + 1; - StackMap prev = map.get(pc); - assert (prev != null); - verification_type_info[] new_locals = new verification_type_info[prev.locals.length + frame.locals.length]; - System.arraycopy(prev.locals, 0, new_locals, 0, prev.locals.length); - System.arraycopy(frame.locals, 0, new_locals, prev.locals.length, frame.locals.length); - StackMap m = new StackMap(new_locals, empty); - map.put(new_pc, m); - return new_pc; - } - - public Integer visit_full_frame(full_frame frame, Integer pc) { - int new_pc = pc + frame.getOffsetDelta() + 1; - StackMap m = new StackMap(frame.locals, frame.stack); - map.put(new_pc, m); - return new_pc; - } - - } - - static class StackMap { - StackMap(verification_type_info[] locals, verification_type_info[] stack) { - this.locals = locals; - this.stack = stack; - } - - private final verification_type_info[] locals; - private final verification_type_info[] stack; - } - - static class CustomVerificationTypeInfo extends verification_type_info { - public CustomVerificationTypeInfo(String text) { - super(-1); - this.text = text; - } - private String text; - } - - private final verification_type_info[] empty = { }; } diff --git a/test/tools/javap/T6824493.java b/test/tools/javap/T6824493.java --- a/test/tools/javap/T6824493.java +++ b/test/tools/javap/T6824493.java @@ -52,8 +52,13 @@ "catch[0]"); test("-XDdetails:stackMaps", - "StackMap locals: this java/lang/String int", - "StackMap stack: java/lang/Throwable"); + "[StackMap]", + "type: same_frame /* 0-63 */", + "locals: this /* init */", + "java/lang/String /* init */", + "int /* 1 */", + "stack: object java/lang/Throwable /* 7 */", + "offset_delta: 12, offset_total: 67"); test("-XDdetails:localVariables", "start local 3 // java.util.List list", diff --git a/test/tools/javap/stackmap/XDdetailsStackMapsTest.java b/test/tools/javap/stackmap/XDdetailsStackMapsTest.java new file mode 100644 --- /dev/null +++ b/test/tools/javap/stackmap/XDdetailsStackMapsTest.java @@ -0,0 +1,147 @@ +/* + * Copyright (c) 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 + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. Oracle designates this + * particular file as subject to the "Classpath" exception as provided + * by Oracle in the LICENSE file that accompanied this code. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +import toolbox.JavapTask; +import toolbox.Task; +import toolbox.ToolBox; + +import java.util.List; + +/* + * @test + * @summary Verify format of -XDdetails:stackMaps + * @modules + * jdk.compiler/com.sun.tools.javac.api + * jdk.compiler/com.sun.tools.javac.main + * jdk.jdeps/com.sun.tools.classfile + * jdk.jdeps/com.sun.tools.javap + * @library /tools/lib + * @build toolbox.ToolBox toolbox.JavacTask toolbox.JavapTask toolbox.Assert + * @run main XDdetailsStackMapsTest + */ +public class XDdetailsStackMapsTest { + + public class Test implements Runnable { + + public void run() { + System.out.println("run..."); + } + + public void main(String[] args) { + Test tcs = new Test(); + + Thread t = new Thread(tcs); + t.start(); + try { + Thread.sleep(2000); + } catch (InterruptedException e) { + System.out.println(e.toString()); + } + } + } + + String ExpectedString = + "Compiled from \"XDdetailsStackMapsTest.java\"\n" + + "public class XDdetailsStackMapsTest$Test implements java.lang.Runnable {\n" + + " final XDdetailsStackMapsTest this$0;\n" + + "\n" + + " public XDdetailsStackMapsTest$Test(XDdetailsStackMapsTest);\n" + + " Code:\n" + + " 0: aload_0\n" + + " 1: aload_1\n" + + " 2: putfield #1 // Field this$0:LXDdetailsStackMapsTest;\n" + + " 5: aload_0\n" + + " 6: invokespecial #2 // Method java/lang/Object.\"\":()V\n" + + " 9: return\n" + + "\n" + + " public void run();\n" + + " Code:\n" + + " 0: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;\n" + + " 3: ldc #4 // String run...\n" + + " 5: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V\n" + + " 8: return\n" + + "\n" + + " public void main(java.lang.String[]);\n" + + " Code:\n" + + " 0: new #6 // class XDdetailsStackMapsTest$Test\n" + + " 3: dup\n" + + " 4: aload_0\n" + + " 5: getfield #1 // Field this$0:LXDdetailsStackMapsTest;\n" + + " 8: invokespecial #7 // Method \"\":(LXDdetailsStackMapsTest;)V\n" + + " 11: astore_2\n" + + " 12: new #8 // class java/lang/Thread\n" + + " 15: dup\n" + + " 16: aload_2\n" + + " 17: invokespecial #9 // Method java/lang/Thread.\"\":(Ljava/lang/Runnable;)V\n" + + " 20: astore_3\n" + + " 21: aload_3\n" + + " 22: invokevirtual #10 // Method java/lang/Thread.start:()V\n" + + " 25: ldc2_w #11 // long 2000l\n" + + " 28: invokestatic #13 // Method java/lang/Thread.sleep:(J)V\n" + + " 31: goto 47\n" + + " [StackMap]\n" + + " type: full_frame /* 255 */\n" + + " locals: object XDdetailsStackMapsTest$Test /* 7 */\n" + + " object [Ljava/lang/String; /* 7 */\n" + + " object XDdetailsStackMapsTest$Test /* 7 */\n" + + " object java/lang/Thread /* 7 */\n" + + " stack: object java/lang/InterruptedException /* 7 */\n" + + " offset_delta: 34, offset_total: 34\n" + + " 34: astore 4\n" + + " 36: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;\n" + + " 39: aload 4\n" + + " 41: invokevirtual #15 // Method java/lang/InterruptedException.toString:()Ljava/lang/String;\n" + + " 44: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V\n" + + " [StackMap]\n" + + " type: same_frame /* 0-63 */\n" + + " locals: object XDdetailsStackMapsTest$Test /* 7 */\n" + + " object [Ljava/lang/String; /* 7 */\n" + + " object XDdetailsStackMapsTest$Test /* 7 */\n" + + " object java/lang/Thread /* 7 */\n" + + " stack: object java/lang/InterruptedException /* 7 */\n" + + " offset_delta: 12, offset_total: 47\n" + + " 47: return\n" + + " Exception table:\n" + + " from to target type\n" + + " 25 31 34 Class java/lang/InterruptedException\n" + + "}\n"; + + public static void main(String... args) { + new XDdetailsStackMapsTest().run(); + } + + void run() { + ToolBox tb = new ToolBox(); + + List res = new JavapTask(tb) + .options("-c", "-XDdetails:stackMaps") + .classes("XDdetailsStackMapsTest.Test") + .run() + .getOutputLines(Task.OutputKind.DIRECT); + List expectedList = tb.split(ExpectedString, "\n"); + + tb.checkEqual(expectedList, res); + } +} \ No newline at end of file From bsrbnd at gmail.com Mon Jan 30 13:50:07 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 30 Jan 2017 14:50:07 +0100 Subject: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules In-Reply-To: <827c07f6-3e3d-7ca9-aa54-b7dbc9efe827@oracle.com> References: <827c07f6-3e3d-7ca9-aa54-b7dbc9efe827@oracle.com> Message-ID: Joe, 2017-01-28 22:39 GMT+01:00 joe darcy : > Hello, > > Please review the straightforward fix to address: > > JDK-8173609: Elements.printElements needs to support modules > http://cr.openjdk.java.net/~darcy/8173609.0/ > > Once additional information about modules is available (JDK-8172810: > ModuleElement should declare and provide appropriate modifiers), the > printing processor should be updated to expose that information. > > Admittedly this changeset would be better with some regression testing. > > Thanks, > > -Joe > Here is a test for that. Regards, Bernard diff --git a/test/tools/javac/modules/T8173609/module-info.java b/test/tools/javac/modules/T8173609/module-info.java new file mode 100644 --- /dev/null +++ b/test/tools/javac/modules/T8173609/module-info.java @@ -0,0 +1,13 @@ +/* + * @test + * @bug 8173609 + * @summary printing of modules + * @compile/ref=module-info.out -Xprint p/P.java module-info.java + */ +module JDK_8173609 { + requires static transitive java.base; + exports p to m.m1, m.m2; + opens p to m.m1, m.m2; + uses p.P; + provides p.P with p.P.P1, p.P.P2; +} diff --git a/test/tools/javac/modules/T8173609/module-info.out b/test/tools/javac/modules/T8173609/module-info.out new file mode 100644 --- /dev/null +++ b/test/tools/javac/modules/T8173609/module-info.out @@ -0,0 +1,23 @@ +package p; + +public class P { + + public static class P1 extends p.P { + + public P1(); + } + + public static class P2 extends p.P { + + public P2(); + } + + public P(); +} +module JDK_8173609 { + requires static transitive java.base; + exports p to m.m1, m.m2; + opens p to m.m1, m.m2; + uses p.P; + provides p.P with p.P.P1, p.P.P2; +} diff --git a/test/tools/javac/modules/T8173609/p/P.java b/test/tools/javac/modules/T8173609/p/P.java new file mode 100644 --- /dev/null +++ b/test/tools/javac/modules/T8173609/p/P.java @@ -0,0 +1,6 @@ +package p; + +public class P { + public static class P1 extends P {} + public static class P2 extends P {} +} From jan.lahoda at oracle.com Mon Jan 30 15:44:13 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 30 Jan 2017 16:44:13 +0100 Subject: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules In-Reply-To: <05a7789a-17f9-a45d-f87f-d6707a02305a@oracle.com> References: <827c07f6-3e3d-7ca9-aa54-b7dbc9efe827@oracle.com> <139379907.2211874.1485688919540.JavaMail.zimbra@u-pem.fr> <05a7789a-17f9-a45d-f87f-d6707a02305a@oracle.com> Message-ID: <588F5F4D.1020105@oracle.com> On 29.1.2017 21:55, joe darcy wrote: > Hi Remi, > > > On 1/29/2017 3:21 AM, Remi Forax wrote: >> Hi Joe, >> i believe that all non public methods you have added can be declared >> private, > > Good point; I'll make that change before pushing. > >> and printNameableList can use a stream and a collector >> >> private void printNameableList(List >> nameables) { >> >> writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(", >> ")); > > I thought of using that style instead and changed some core reflection > code to use streams and collectors earlier in 9 (JDK-8162817: Annotation > toString output not reusable for source input). > > I'll let Jon or Jan weigh in on which style is preferred for javac. I personally think both are fine here: using stream and collector avoids the auxiliary variable ("first"); using the loop avoids the need to construct the compound string by writing the elements to the output one by one. Jan > > Thanks, > > -Joe > >> } >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "joe darcy" >>> ?: compiler-dev at openjdk.java.net >>> Envoy?: Samedi 28 Janvier 2017 22:39:26 >>> Objet: JDK 9 RFR of JDK-8173609: Elements.printElements needs to >>> support modules >>> Hello, >>> >>> Please review the straightforward fix to address: >>> >>> JDK-8173609: Elements.printElements needs to support modules >>> http://cr.openjdk.java.net/~darcy/8173609.0/ >>> >>> Once additional information about modules is available (JDK-8172810: >>> ModuleElement should declare and provide appropriate modifiers), the >>> printing processor should be updated to expose that information. >>> >>> Admittedly this changeset would be better with some regression testing. >>> >>> Thanks, >>> >>> -Joe > From jonathan.gibbons at oracle.com Mon Jan 30 22:04:57 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 30 Jan 2017 14:04:57 -0800 Subject: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules In-Reply-To: <05a7789a-17f9-a45d-f87f-d6707a02305a@oracle.com> References: <827c07f6-3e3d-7ca9-aa54-b7dbc9efe827@oracle.com> <139379907.2211874.1485688919540.JavaMail.zimbra@u-pem.fr> <05a7789a-17f9-a45d-f87f-d6707a02305a@oracle.com> Message-ID: <588FB889.5020207@oracle.com> On 01/29/2017 12:55 PM, joe darcy wrote: > Hi Remi, > > > On 1/29/2017 3:21 AM, Remi Forax wrote: >> Hi Joe, >> i believe that all non public methods you have added can be declared >> private, > > Good point; I'll make that change before pushing. > >> and printNameableList can use a stream and a collector >> >> private void printNameableList(List >> nameables) { >> writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(", >> ")); > > I thought of using that style instead and changed some core reflection > code to use streams and collectors earlier in 9 (JDK-8162817: > Annotation toString output not reusable for source input). > > I'll let Jon or Jan weigh in on which style is preferred for javac. We recently did a pass over javac code to modernize code, so these days, I think streams and collectors are fine. The primary criteria are regard for the bootstrap process, and no large destabilizing changes that might advesely impact forward/backward parts at the beginning of a release cycle. We can maybe quibble over the formatting: one line, or one line per chained method. :-) -- Jon > > Thanks, > > -Joe > >> } >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "joe darcy" >>> ?: compiler-dev at openjdk.java.net >>> Envoy?: Samedi 28 Janvier 2017 22:39:26 >>> Objet: JDK 9 RFR of JDK-8173609: Elements.printElements needs to >>> support modules >>> Hello, >>> >>> Please review the straightforward fix to address: >>> >>> JDK-8173609: Elements.printElements needs to support modules >>> http://cr.openjdk.java.net/~darcy/8173609.0/ >>> >>> Once additional information about modules is available (JDK-8172810: >>> ModuleElement should declare and provide appropriate modifiers), the >>> printing processor should be updated to expose that information. >>> >>> Admittedly this changeset would be better with some regression testing. >>> >>> Thanks, >>> >>> -Joe > From joe.darcy at oracle.com Mon Jan 30 22:20:07 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 30 Jan 2017 14:20:07 -0800 Subject: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules In-Reply-To: <588FB889.5020207@oracle.com> References: <827c07f6-3e3d-7ca9-aa54-b7dbc9efe827@oracle.com> <139379907.2211874.1485688919540.JavaMail.zimbra@u-pem.fr> <05a7789a-17f9-a45d-f87f-d6707a02305a@oracle.com> <588FB889.5020207@oracle.com> Message-ID: <1c9f2fa8-675d-bbc3-e261-a768cf3602c0@oracle.com> Hi Jon, On 1/30/2017 2:04 PM, Jonathan Gibbons wrote: > > > On 01/29/2017 12:55 PM, joe darcy wrote: >> Hi Remi, >> >> >> On 1/29/2017 3:21 AM, Remi Forax wrote: >>> Hi Joe, >>> i believe that all non public methods you have added can be declared >>> private, >> >> Good point; I'll make that change before pushing. >> >>> and printNameableList can use a stream and a collector >>> >>> private void printNameableList(List >>> nameables) { >>> writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(", >>> ")); >> >> I thought of using that style instead and changed some core >> reflection code to use streams and collectors earlier in 9 >> (JDK-8162817: Annotation toString output not reusable for source input). >> >> I'll let Jon or Jan weigh in on which style is preferred for javac. > > We recently did a pass over javac code to modernize code, so these > days, I think streams and collectors are fine. The primary criteria > are regard for the bootstrap process, and no large destabilizing > changes that might advesely impact forward/backward parts at the > beginning of a release cycle. > > We can maybe quibble over the formatting: one line, or one line per > chained method. :-) > Replaced with for-loop and state variable over names with + private void printNameableList(List nameables) { + writer.print(nameables.stream(). + map(QualifiedNameable::getQualifiedName). + collect(Collectors.joining(", "))); + } and verified the output for java.base was the same as before. -Joe From forax at univ-mlv.fr Mon Jan 30 22:26:10 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 30 Jan 2017 23:26:10 +0100 (CET) Subject: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules In-Reply-To: <588FB889.5020207@oracle.com> References: <827c07f6-3e3d-7ca9-aa54-b7dbc9efe827@oracle.com> <139379907.2211874.1485688919540.JavaMail.zimbra@u-pem.fr> <05a7789a-17f9-a45d-f87f-d6707a02305a@oracle.com> <588FB889.5020207@oracle.com> Message-ID: <1545796888.599878.1485815170697.JavaMail.zimbra@u-pem.fr> Jon, all, i've found that Streams are great until you use polymorphic methods in lambdas that are parameters of map(), flatMap(), filter() etc because when you debug, the stacktrace will be quite big, and jump on methods you have no control over. So i tend to use Stream in my code when the stream call methods i know the implementations and use loops otherwise. R?mi ----- Mail original ----- > De: "Jonathan Gibbons" > ?: compiler-dev at openjdk.java.net > Envoy?: Lundi 30 Janvier 2017 23:04:57 > Objet: Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules > On 01/29/2017 12:55 PM, joe darcy wrote: >> Hi Remi, >> >> >> On 1/29/2017 3:21 AM, Remi Forax wrote: >>> Hi Joe, >>> i believe that all non public methods you have added can be declared >>> private, >> >> Good point; I'll make that change before pushing. >> >>> and printNameableList can use a stream and a collector >>> >>> private void printNameableList(List >>> nameables) { >>> writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(", >>> ")); >> >> I thought of using that style instead and changed some core reflection >> code to use streams and collectors earlier in 9 (JDK-8162817: >> Annotation toString output not reusable for source input). >> >> I'll let Jon or Jan weigh in on which style is preferred for javac. > > We recently did a pass over javac code to modernize code, so these days, > I think streams and collectors are fine. The primary criteria are regard > for the bootstrap process, and no large destabilizing changes that might > advesely impact forward/backward parts at the beginning of a release cycle. > > We can maybe quibble over the formatting: one line, or one line per > chained method. :-) > > -- Jon > >> >> Thanks, >> >> -Joe >> >>> } >>> >>> cheers, >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "joe darcy" >>>> ?: compiler-dev at openjdk.java.net >>>> Envoy?: Samedi 28 Janvier 2017 22:39:26 >>>> Objet: JDK 9 RFR of JDK-8173609: Elements.printElements needs to >>>> support modules >>>> Hello, >>>> >>>> Please review the straightforward fix to address: >>>> >>>> JDK-8173609: Elements.printElements needs to support modules >>>> http://cr.openjdk.java.net/~darcy/8173609.0/ >>>> >>>> Once additional information about modules is available (JDK-8172810: >>>> ModuleElement should declare and provide appropriate modifiers), the >>>> printing processor should be updated to expose that information. >>>> >>>> Admittedly this changeset would be better with some regression testing. >>>> >>>> Thanks, >>>> >>>> -Joe From jonathan.gibbons at oracle.com Mon Jan 30 22:30:00 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 30 Jan 2017 14:30:00 -0800 Subject: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules In-Reply-To: <1545796888.599878.1485815170697.JavaMail.zimbra@u-pem.fr> References: <827c07f6-3e3d-7ca9-aa54-b7dbc9efe827@oracle.com> <139379907.2211874.1485688919540.JavaMail.zimbra@u-pem.fr> <05a7789a-17f9-a45d-f87f-d6707a02305a@oracle.com> <588FB889.5020207@oracle.com> <1545796888.599878.1485815170697.JavaMail.zimbra@u-pem.fr> Message-ID: <588FBE68.4060802@oracle.com> Remi, That sounds like interesting feedback for the streams() folk. I don't this we can rely on most folk making informed judgements based on implementation details :-( -- Jon On 01/30/2017 02:26 PM, Remi Forax wrote: > Jon, all, > i've found that Streams are great until you use polymorphic methods in lambdas that are parameters of map(), flatMap(), filter() etc because when you debug, the stacktrace will be quite big, and jump on methods you have no control over. > So i tend to use Stream in my code when the stream call methods i know the implementations and use loops otherwise. > > R?mi > > ----- Mail original ----- >> De: "Jonathan Gibbons" >> ?: compiler-dev at openjdk.java.net >> Envoy?: Lundi 30 Janvier 2017 23:04:57 >> Objet: Re: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules >> On 01/29/2017 12:55 PM, joe darcy wrote: >>> Hi Remi, >>> >>> >>> On 1/29/2017 3:21 AM, Remi Forax wrote: >>>> Hi Joe, >>>> i believe that all non public methods you have added can be declared >>>> private, >>> Good point; I'll make that change before pushing. >>> >>>> and printNameableList can use a stream and a collector >>>> >>>> private void printNameableList(List >>>> nameables) { >>>> writer.print(nameables.stream().map(QualifiedNameable::getQualifiedName).collect(Collectors.joining(", >>>> ")); >>> I thought of using that style instead and changed some core reflection >>> code to use streams and collectors earlier in 9 (JDK-8162817: >>> Annotation toString output not reusable for source input). >>> >>> I'll let Jon or Jan weigh in on which style is preferred for javac. >> We recently did a pass over javac code to modernize code, so these days, >> I think streams and collectors are fine. The primary criteria are regard >> for the bootstrap process, and no large destabilizing changes that might >> advesely impact forward/backward parts at the beginning of a release cycle. >> >> We can maybe quibble over the formatting: one line, or one line per >> chained method. :-) >> >> -- Jon >> >>> Thanks, >>> >>> -Joe >>> >>>> } >>>> >>>> cheers, >>>> R?mi >>>> >>>> ----- Mail original ----- >>>>> De: "joe darcy" >>>>> ?: compiler-dev at openjdk.java.net >>>>> Envoy?: Samedi 28 Janvier 2017 22:39:26 >>>>> Objet: JDK 9 RFR of JDK-8173609: Elements.printElements needs to >>>>> support modules >>>>> Hello, >>>>> >>>>> Please review the straightforward fix to address: >>>>> >>>>> JDK-8173609: Elements.printElements needs to support modules >>>>> http://cr.openjdk.java.net/~darcy/8173609.0/ >>>>> >>>>> Once additional information about modules is available (JDK-8172810: >>>>> ModuleElement should declare and provide appropriate modifiers), the >>>>> printing processor should be updated to expose that information. >>>>> >>>>> Admittedly this changeset would be better with some regression testing. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe From joe.darcy at oracle.com Mon Jan 30 23:15:14 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 30 Jan 2017 15:15:14 -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> Message-ID: <588FC902.9070008@oracle.com> Hi Bernard, On 1/30/2017 5:50 AM, B. Blaser wrote: > Joe, > > 2017-01-28 22:39 GMT+01:00 joe darcy : >> Hello, >> >> Please review the straightforward fix to address: >> >> JDK-8173609: Elements.printElements needs to support modules >> http://cr.openjdk.java.net/~darcy/8173609.0/ >> >> Once additional information about modules is available (JDK-8172810: >> ModuleElement should declare and provide appropriate modifiers), the >> printing processor should be updated to expose that information. >> >> Admittedly this changeset would be better with some regression testing. >> >> Thanks, >> >> -Joe >> > Here is a test for that. > Regards, > 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 > > diff --git a/test/tools/javac/modules/T8173609/module-info.java > b/test/tools/javac/modules/T8173609/module-info.java > new file mode 100644 > --- /dev/null > +++ b/test/tools/javac/modules/T8173609/module-info.java > @@ -0,0 +1,13 @@ > +/* > + * @test > + * @bug 8173609 > + * @summary printing of modules > + * @compile/ref=module-info.out -Xprint p/P.java module-info.java > + */ > +module JDK_8173609 { > + requires static transitive java.base; > + exports p to m.m1, m.m2; > + opens p to m.m1, m.m2; > + uses p.P; > + provides p.P with p.P.P1, p.P.P2; > +} > diff --git a/test/tools/javac/modules/T8173609/module-info.out > b/test/tools/javac/modules/T8173609/module-info.out > new file mode 100644 > --- /dev/null > +++ b/test/tools/javac/modules/T8173609/module-info.out > @@ -0,0 +1,23 @@ > +package p; > + > +public class P { > + > + public static class P1 extends p.P { > + > + public P1(); > + } > + > + public static class P2 extends p.P { > + > + public P2(); > + } > + > + public P(); > +} > +module JDK_8173609 { > + requires static transitive java.base; > + exports p to m.m1, m.m2; > + opens p to m.m1, m.m2; > + uses p.P; > + provides p.P with p.P.P1, p.P.P2; > +} > diff --git a/test/tools/javac/modules/T8173609/p/P.java > b/test/tools/javac/modules/T8173609/p/P.java > new file mode 100644 > --- /dev/null > +++ b/test/tools/javac/modules/T8173609/p/P.java > @@ -0,0 +1,6 @@ > +package p; > + > +public class P { > + public static class P1 extends P {} > + public static class P2 extends P {} > +} From jonathan.gibbons at oracle.com Tue Jan 31 00:49:24 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 30 Jan 2017 16:49:24 -0800 Subject: RFR: 8172810: ModuleElement should declare and provide appropriate modifiers Message-ID: <588FDF14.2000801@oracle.com> Simple review to add ModuleElement.isOpen. JIRA: https://bugs.openjdk.java.net/browse/JDK-8172810 Webrev: http://cr.openjdk.java.net/~jjg/8172810/webrev.00/ -- Jon From jonathan.gibbons at oracle.com Tue Jan 31 01:04:22 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 30 Jan 2017 17:04:22 -0800 Subject: RFR: 8172810: ModuleElement should declare and provide appropriate modifiers In-Reply-To: <588FDF14.2000801@oracle.com> References: <588FDF14.2000801@oracle.com> Message-ID: <588FE296.9070908@oracle.com> Update to update the PrintingProcessor: Webrev: http://cr.openjdk.java.net/~jjg/8172810/webrev.01/ -- Jon On 01/30/2017 04:49 PM, Jonathan Gibbons wrote: > Simple review to add ModuleElement.isOpen. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8172810 > Webrev: http://cr.openjdk.java.net/~jjg/8172810/webrev.00/ > > -- Jon > From joe.darcy at oracle.com Tue Jan 31 01:09:04 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 30 Jan 2017 17:09:04 -0800 Subject: RFR: 8172810: ModuleElement should declare and provide appropriate modifiers In-Reply-To: <588FE296.9070908@oracle.com> References: <588FDF14.2000801@oracle.com> <588FE296.9070908@oracle.com> Message-ID: <588FE3B0.4020506@oracle.com> Looks good Jon; thanks, -Joe On 1/30/2017 5:04 PM, Jonathan Gibbons wrote: > Update to update the PrintingProcessor: > > Webrev: http://cr.openjdk.java.net/~jjg/8172810/webrev.01/ > > -- Jon > > > On 01/30/2017 04:49 PM, Jonathan Gibbons wrote: >> Simple review to add ModuleElement.isOpen. >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8172810 >> Webrev: http://cr.openjdk.java.net/~jjg/8172810/webrev.00/ >> >> -- Jon >> > From joe.darcy at oracle.com Tue Jan 31 08:29:44 2017 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 31 Jan 2017 00:29:44 -0800 Subject: JDK 9 RFR of JDK-8173676: Improvements to javax.annotation.processing and javax.lang.model doc Message-ID: <45319881-34bb-bcf1-0170-c6f187b65844@oracle.com> Hello, I've read over all the javax.annotation.processing and javax.lang.model API looking for remaining work that should be done in JDK 9. The first part of this small improvements and clarifications that should be made. Please review: http://cr.openjdk.java.net/~darcy/8173676.0/ Strictly speaking, these are generally clarifications of the existing specification rather than specification changes per se. In the next few days, I plan to propose a few small API changes, such as changing several more new methods on interfaces to default methods. Thanks, -Joe From bsrbnd at gmail.com Tue Jan 31 12:59:02 2017 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 31 Jan 2017 13:59:02 +0100 Subject: JDK 9 RFR of JDK-8173609: Elements.printElements needs to support modules In-Reply-To: <588FC902.9070008@oracle.com> References: <827c07f6-3e3d-7ca9-aa54-b7dbc9efe827@oracle.com> <588FC902.9070008@oracle.com> Message-ID: 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 diff --git a/test/tools/javac/processing/model/util/printing/module-info.java b/test/tools/javac/processing/model/util/printing/module-info.java new file mode 100644 --- /dev/null +++ b/test/tools/javac/processing/model/util/printing/module-info.java @@ -0,0 +1,18 @@ +/* + * @test + * @bug 8173609 + * @summary printing of modules + * @compile/ref=module-info.out -Xprint p/P.java module-info.java + */ + +/** + * Printing of modules + */ + at Deprecated +module printing { + requires static transitive java.base; + exports p to m.m1, m.m2; + opens p to m.m1, m.m2; + uses p.P; + provides p.P with p.P.P1, p.P.P2; +} diff --git a/test/tools/javac/processing/model/util/printing/module-info.out b/test/tools/javac/processing/model/util/printing/module-info.out new file mode 100644 --- /dev/null +++ b/test/tools/javac/processing/model/util/printing/module-info.out @@ -0,0 +1,27 @@ +package p; + +public class P { + + public static class P1 extends p.P { + + public P1(); + } + + public static class P2 extends p.P { + + public P2(); + } + + public P(); +} +/** + * Printing of modules + */ + at java.lang.Deprecated +module printing { + requires static transitive java.base; + exports p to m.m1, m.m2; + opens p to m.m1, m.m2; + uses p.P; + provides p.P with p.P.P1, p.P.P2; +} diff --git a/test/tools/javac/processing/model/util/printing/p/P.java b/test/tools/javac/processing/model/util/printing/p/P.java new file mode 100644 --- /dev/null +++ b/test/tools/javac/processing/model/util/printing/p/P.java @@ -0,0 +1,6 @@ +package p; + +public class P { + public static class P1 extends P {} + public static class P2 extends P {} +} From jonathan.gibbons at oracle.com Tue Jan 31 21:50:54 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 31 Jan 2017 13:50:54 -0800 Subject: RFR: 8172309: classpath wildcards code does not support --class-path In-Reply-To: <30EF55B3-B321-4488-BFAD-1993E0F31A6C@oracle.com> References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com> <588A78AE.9020101@oracle.com> <588A8FB5.5020601@oracle.com> <30EF55B3-B321-4488-BFAD-1993E0F31A6C@oracle.com> Message-ID: <589106BE.6010402@oracle.com> OK -- Jon On 01/27/2017 01:12 PM, Henry Jen wrote: > How about following patch instead for langtools repo? > > diff -r ef142ac9824e test/tools/javac/Paths/wcMineField.sh > --- a/test/tools/javac/Paths/wcMineField.sh Thu Jan 26 16:53:56 2017 -0800 > +++ b/test/tools/javac/Paths/wcMineField.sh Fri Jan 27 13:10:12 2017 -0800 > @@ -26,7 +26,7 @@ > # > # @test > # @summary Test classpath wildcards for javac and java -classpath option. > -# @bug 6268383 > +# @bug 6268383 8172309 > # @run shell/timeout=600 wcMineField.sh > > # To run this test manually, simply do ./wcMineField.sh > @@ -186,6 +186,8 @@ > Failure "$javac" ${TESTTOOLVMOPTS} -classpath "GooJar/*${PS}." Main1.java > Success "$javac" ${TESTTOOLVMOPTS} -cp "GooJar/SubDir/*" Main1.java > Success "$javac" ${TESTTOOLVMOPTS} -classpath "GooJar/SubDir/*" Main1.java > +Success "$javac" ${TESTTOOLVMOPTS} --class-path "GooJar/SubDir/*" Main1.java > +Success "$javac" ${TESTTOOLVMOPTS} --class-path="GooJar/SubDir/*" Main1.java > #Same with launcher. Should not load jar in subdirectories unless specified > Failure "$java" ${TESTVMOPTS} -classpath "GooJar/*${PS}." Main1 > Success "$java" ${TESTVMOPTS} -classpath "GooJar/SubDir/*${PS}." Main1 > > Cheers, > Henry > > >> On Jan 26, 2017, at 6:01 PM, Henry Jen wrote: >> >>> On Jan 26, 2017, at 4:09 PM, Jonathan Gibbons wrote: >>> >>> Henry, >>> >>> You've changed old test cases into new test cases, thereby eliminating the old cases, which is not so good. >>> >>> You should be adding new test cases, but changing old ones. >>> >> I am not sure, I believe all wild-card cases still tested, just that we have different variety of calling -cp. Of course, it would be nice to test all cases with all 4 flavors of -cp, but I don?t think that?s necessary as I think the test coverage is the same. >> >> Anyway, I could be wrong. If you feel strong about this, I can redo it. But that may takes more time to digest what the test cases are really for. >> >> Cheers, >> Henry >> >> >>> -- Jon >>> >>> >>> On 01/26/2017 02:31 PM, Kumar Srinivasan wrote: >>>> Hi Henry, >>>> >>>> Looks ok to me. Thanks for making this change. >>>> >>>> Kumar >>>> >>>>> Hi, >>>>> >>>>> Please review the webrev[1], the fix is to ensure ?class-path and ?class-path= is processed correctly to expand wildcard. Changes are made in jdk repo. However, test case to verify the bug fix is in langtool repo. >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/ >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8172309 From stephan.herrmann at berlin.de Tue Jan 31 22:35:24 2017 From: stephan.herrmann at berlin.de (Stephan Herrmann) Date: Tue, 31 Jan 2017 23:35:24 +0100 Subject: Another gap in JVMS 4.7.9.1 Message-ID: <131b4b62-6457-fd30-1531-bcf7e819b23b@berlin.de> This loosely relates to the recent thread "spec clarification: wildcard array element signature". JVMS seems to be lacking a definition how capture variables should be encoded in class file attributes. Until recently we believed this to be relevant only for LVTT, where - according to javac - simply *not* generating an entry *could* be a viable workaround. Recently, s.o. reported the following program: ----- public class Bug494198 { class Inner { } public static void main(String[] args) { Bug494198 outer=new Bug494198<>(); Object inner=outer.new Inner() { public String toString() { return getClass().getGenericSuperclass().toString(); } }; System.out.println(inner); } } ----- When compiled with javac and run with java it throws GenericSignatureFormatError. Inspecting Bug494198$1.class with javap shows: ---- final class Bug494198$1 extends Bug494198<>.Inner ---- The outer type argument is mandatory, but JVMS doesn't give an answer as to what should be generated there. For implementation reasons, ecj represents the wildcard as "!". Neither is correct, it seems no answer *can* be correct against current JVMS. I could imagine that even those "fresh type variables" introduced via JLS 18.4 need to appear in class file attributes in special situations. While the above may be a contrived example, wanting to generate LVTT with captures involved has been observed in real world examples. thanks, Stephan From martinrb at google.com Tue Jan 31 23:13:50 2017 From: martinrb at google.com (Martin Buchholz) Date: Tue, 31 Jan 2017 15:13:50 -0800 Subject: RFR: 8172309: classpath wildcards code does not support --class-path In-Reply-To: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com> References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com> Message-ID: I would try to avoid having the wildcard code know about the various ways of specifying classpath. We now have 3 different classpath flags - can they be canonicalized into one form before wildcard handling? On Wed, Jan 25, 2017 at 1:23 PM, Henry Jen wrote: > Hi, > > Please review the webrev[1], the fix is to ensure ?class-path and > ?class-path= is processed correctly to expand wildcard. Changes are made in > jdk repo. However, test case to verify the bug fix is in langtool repo. > > Cheers, > Henry > > [1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/ > [2] https://bugs.openjdk.java.net/browse/JDK-8172309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Tue Jan 31 23:18:47 2017 From: martinrb at google.com (Martin Buchholz) Date: Tue, 31 Jan 2017 15:18:47 -0800 Subject: RFR: 8172309: classpath wildcards code does not support --class-path In-Reply-To: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com> References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com> Message-ID: Can we have tests in sets of threes, checking -cp, -classpath, --class-path (and perhaps also CLASSPATH environment) --- a/test/tools/launcher/ClassPathWildCard.sh +++ b/test/tools/launcher/ClassPathWildCard.sh @@ -125,7 +125,7 @@ CheckFail TestA rm -f TestB${OUTEXT} - $JAVA${variant} -classpath JarDir/"*"$NOOP TestB || exit 1 + $JAVA${variant} -cp JarDir/"*"$NOOP TestB || exit 1 CheckFail TestB @@ -134,11 +134,11 @@ cp TestD/*.class JarDir rm -f TestC${OUTEXT} - $JAVA${variant} -classpath JarDir${PATHSEP}JarDir/"*"$NOOP TestC || exit 1 + $JAVA${variant} --class-path JarDir${PATHSEP}JarDir/"*"$NOOP TestC || exit 1 CheckFail TestC rm -f TestD${OUTEXT} - $JAVA${variant} -classpath JarDir${PATHSEP}JarDir/"*"$NOOP TestD || exit 1 + $JAVA${variant} --class-path=JarDir${PATHSEP}JarDir/"*"$NOOP TestD || exit 1 CheckFail TestD -------------- next part -------------- An HTML attachment was scrubbed... URL: