From jan.lahoda at oracle.com Wed Aug 1 06:28:32 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 1 Aug 2018 08:28:32 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B5BA6E2.9000208@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> Message-ID: <5B615310.2030702@oracle.com> Hi Jon, Thanks for the comments! An updated webrev that reflects the comments is here: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ A delta webrev between this webrev and the webrev.00 is here: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ Does this look better? Thanks! Jan On 28.7.2018 01:12, Jonathan Gibbons wrote: > CaseTree.java:52: spelling, "lables" > > CaseTree.java:84: "return" should be "returns". > > Lots of @Deprecated annotations without corresponding @deprecated > javadoc tag. > Should the @apiNote really be @deprecated. I also think that using > @Deprecated > like this is "a bit smelly", and had a discussion with Stuart "Dr > Deprecator" regarding > my concerns. If nothing else, assuming the feature is a success, we are > setting up > a precedent of marking an API as deprecated-for-removal, and then in the > next > release, simply removing the annotation. > > Attr.java:1482: ugly use of @SuppressWarnings. I understand why it is > there, > but it exemplifies why @Deprecated on the declaration is a bad idea. > It'll be too easy to not remove these annotations in JDK 13. > > Attr:1825: why XXX > > LambdaToMethod: unnecessary new import, CaseKind > Flow: unnecessary new import, CaseKind > > JavacParser: order of imports > > messages: generally, I think the text of the messages could be improved > (related but not new) we should somehow identify language keywords from > English text (i.e. words like `break, `case`, `continue`, `return`) > 204: saying the name is both a valid label and a valid expression hints > at the cause but not the error (i.e. the name is ambiguous) > > JCTree: inconsistent layout of annotations; inconsistent use of > @Deprecated and @Deprecated(forRemoval=true) > > (tests) > Not reviewed in detail yet. > New test descriptions should use "/*" for jtreg comment block; not > "/**". These are not javadoc documentation comments. > New test descriptions should have @summary > Presumably, we will have to change the -old.out files if the preview > feature becomes standard in JDK 13. > > > Overall, > > The logic is nice, but the use of @Deprecated(forRemoval=true) and > resulting @SuppressWarnings really suck. > I don't think the current practice is serving us well. > > -- Jon > > > On 07/17/2018 11:00 AM, Jan Lahoda wrote: >> Hi, >> >> As JEP 325 is in the proposed to target state, I thought it might be a >> good idea to start a review process for the code. >> >> The code here strives to implement the current specification for the >> Switch Expressions: >> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >> >> The current webrev is here: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >> >> (includes a list of new errors.) >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8192963 >> https://bugs.openjdk.java.net/browse/JDK-8206986 >> >> CSRs: >> https://bugs.openjdk.java.net/browse/JDK-8207241 >> https://bugs.openjdk.java.net/browse/JDK-8207406 >> >> Any feedback is welcome! >> >> Thanks, >> Jan > From maurizio.cimadamore at oracle.com Wed Aug 1 14:04:16 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 1 Aug 2018 15:04:16 +0100 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B615310.2030702@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> Message-ID: <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> Hi Jan, great work, some comments below. * Diagnostics. I see that some diagnostics seem to be inconsistent with what we do for 'return' - e.g. javac diagnostics for 'return' are quite succint: - "return outside method" - "missing return statement" - "unexpected return value" - "error: incompatible types: String cannot be converted to int" The analogous conditions for break in switch expression seem to be more verbose: - "expression break not immediately enclosed by a switch expression" - "break is missing a value to return from switch expression" - There's no equivalent for the third above - probably the closest condition would be to 'break expr' from a switch statement, in which case I bet you get a 'missing label' error - should we rectify that too? - "incompatible types: bad type in switch expression" ... (A cannot be converted to B) Not sure whether we should try to maintain the same style across break/return, but it seemed worth at least pointing out. Other diagnostic comments: - "error: j is ambiguously both a valid expression and a valid label" - this seems convoluted, I would personally rephrase as something like: ambiguous reference to 'j' ... ('j' is both a label and an expression) - "break is jumping outside of the enclosing switch expression" -> "break outside of enclosing switch expression" - "continue is jumping outside of the enclosing switch expression" -> "continue outside of enclosing switch expression" * Attr - The refactoring of switchExpr into switch + handleSwitch is very sweet - I like it! * Flow - a bit odd that we have to make up a new tree to call recordExit - but I see why you're doing it :-) * Lower - it would be nice to have a comment on SwitchExpression that shows what the generated code shape looks like; I think we do that for other non-trivial translations (e.g. for each) * ExpSwitchNestingTest - I see that this test is not using the newer combo framework. Actually, I'm not even sure this one needs any templating logic at all, as it seems the test is doing its own replacements. But I was going to note that this test is not using the shared context enhancements, which I guess it's still ok given the number of combinations checked is low. Maybe worth keeping an eye on this in the future, should we keep adding new cases to it. Maurizio On 01/08/18 07:28, Jan Lahoda wrote: > Hi Jon, > > Thanks for the comments! > > An updated webrev that reflects the comments is here: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ > > A delta webrev between this webrev and the webrev.00 is here: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ > > Does this look better? > > Thanks! > > Jan > > On 28.7.2018 01:12, Jonathan Gibbons wrote: >> CaseTree.java:52: spelling, "lables" >> >> CaseTree.java:84:? "return" should be "returns". >> >> Lots of @Deprecated annotations without corresponding @deprecated >> javadoc tag. >> Should the @apiNote really be @deprecated.? I also think that using >> @Deprecated >> like this is "a bit smelly", and had a discussion with Stuart "Dr >> Deprecator" regarding >> my concerns. If nothing else, assuming the feature is a success, we are >> setting up >> a precedent of marking an API as deprecated-for-removal, and then in the >> next >> release, simply removing the annotation. >> >> Attr.java:1482: ugly use of @SuppressWarnings. I understand why it is >> there, >> but it exemplifies why @Deprecated on the declaration is a bad idea. >> It'll be too easy to not remove these annotations in JDK 13. >> >> Attr:1825: why XXX >> >> LambdaToMethod: unnecessary new import, CaseKind >> Flow: unnecessary new import, CaseKind >> >> JavacParser: order of imports >> >> messages: generally, I think the text of the messages could be improved >> (related but not new) we should somehow identify language keywords from >> English text (i.e. words like `break, `case`, `continue`, `return`) >> 204: saying the name is both a valid label and a valid expression hints >> at the cause but not the error (i.e. the name is ambiguous) >> >> JCTree: inconsistent layout of annotations; inconsistent use of >> @Deprecated and @Deprecated(forRemoval=true) >> >> (tests) >> Not reviewed in detail yet. >> New test descriptions should use "/*" for jtreg comment block; not >> "/**". These are not javadoc documentation comments. >> New test descriptions should have @summary >> Presumably, we will have to change the -old.out files if the preview >> feature becomes standard in JDK 13. >> >> >> Overall, >> >> The logic is nice, but the use of @Deprecated(forRemoval=true) and >> resulting @SuppressWarnings really suck. >> I don't think the current practice is serving us well. >> >> -- Jon >> >> >> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>> Hi, >>> >>> As JEP 325 is in the proposed to target state, I thought it might be a >>> good idea to start a review process for the code. >>> >>> The code here strives to implement the current specification for the >>> Switch Expressions: >>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>> >>> The current webrev is here: >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>> >>> (includes a list of new errors.) >>> >>> JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>> >>> CSRs: >>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>> >>> Any feedback is welcome! >>> >>> Thanks, >>> ??? Jan >> From jan.lahoda at oracle.com Wed Aug 1 15:43:23 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 1 Aug 2018 17:43:23 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> Message-ID: <5B61D51B.3070905@oracle.com> Hi Maurizio, Thanks for the comments - responses are inlined. On 1.8.2018 16:04, Maurizio Cimadamore wrote: > Hi Jan, > great work, some comments below. > > * Diagnostics. I see that some diagnostics seem to be inconsistent with > what we do for 'return' - e.g. javac diagnostics for 'return' are quite > succint: > > - "return outside method" > > - "missing return statement" > > - "unexpected return value" > > - "error: incompatible types: String cannot be converted to int" > > The analogous conditions for break in switch expression seem to be more > verbose: > > - "expression break not immediately enclosed by a switch expression" I think the closest error to "return outside method" is "value break outside of switch expression". The "expression break not immediately enclosed by a switch expression" is used when the break is inside another breakable statement inside the switch expression. I guess this should be rephrased at least to "value break not immediately enclosed by switch expression". > > - "break is missing a value to return from switch expression" How about "missing break value"? (the break is present, but the value is missing.) > > - There's no equivalent for the third above - probably the closest > condition would be to 'break expr' from a switch statement, in which > case I bet you get a 'missing label' error - should we rectify that too? There are several conditions, and the error differ, consider: --- public class SwitchExpr { private void breakTest(int e) { break ; break x; break (e); while (true) { break x; break (e); } } } --- This gives: --- SwitchExpr.java:3: error: break outside switch or loop break ; ^ SwitchExpr.java:4: error: undefined label: x break x; ^ SwitchExpr.java:5: error: value break outside of switch expression break (e); ^ SwitchExpr.java:7: error: undefined label: x break x; ^ SwitchExpr.java:8: error: value break outside of switch expression break (e); ^ 5 errors --- So when it is clear the break is a value break, a value break related diagnostic is reported, otherwise, the errors fall back to the existing diagnostics of cannot find labels. > > - "incompatible types: bad type in switch expression" > ... > (A cannot be converted to B) I think this was modelled based on conditional expressions: SwitchExpr.java:10: error: incompatible types: bad type in conditional expression B b = e == 0 ? (A) null : (B) null; ^ A cannot be converted to B I'll look if this can be changed. > > Not sure whether we should try to maintain the same style across > break/return, but it seemed worth at least pointing out. > > Other diagnostic comments: > > - "error: j is ambiguously both a valid expression and a valid label" - > this seems convoluted, I would personally rephrase as something like: > > ambiguous reference to 'j' > ... > ('j' is both a label and an expression) Will done. > > - "break is jumping outside of the enclosing switch expression" -> > "break outside of enclosing switch expression" Will do. > > - "continue is jumping outside of the enclosing switch expression" -> > "continue outside of enclosing switch expression" Will do. > > * Attr - The refactoring of switchExpr into switch + handleSwitch is > very sweet - I like it! > > * Flow - a bit odd that we have to make up a new tree to call recordExit > - but I see why you're doing it :-) > > * Lower - it would be nice to have a comment on SwitchExpression that > shows what the generated code shape looks like; I think we do that for > other non-trivial translations (e.g. for each) Will do. Thanks, Jan > > * ExpSwitchNestingTest - I see that this test is not using the newer > combo framework. Actually, I'm not even sure this one needs any > templating logic at all, as it seems the test is doing its own > replacements. But I was going to note that this test is not using the > shared context enhancements, which I guess it's still ok given the > number of combinations checked is low. Maybe worth keeping an eye on > this in the future, should we keep adding new cases to it. > > Maurizio > > On 01/08/18 07:28, Jan Lahoda wrote: >> Hi Jon, >> >> Thanks for the comments! >> >> An updated webrev that reflects the comments is here: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ >> >> A delta webrev between this webrev and the webrev.00 is here: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ >> >> Does this look better? >> >> Thanks! >> >> Jan >> >> On 28.7.2018 01:12, Jonathan Gibbons wrote: >>> CaseTree.java:52: spelling, "lables" >>> >>> CaseTree.java:84: "return" should be "returns". >>> >>> Lots of @Deprecated annotations without corresponding @deprecated >>> javadoc tag. >>> Should the @apiNote really be @deprecated. I also think that using >>> @Deprecated >>> like this is "a bit smelly", and had a discussion with Stuart "Dr >>> Deprecator" regarding >>> my concerns. If nothing else, assuming the feature is a success, we are >>> setting up >>> a precedent of marking an API as deprecated-for-removal, and then in the >>> next >>> release, simply removing the annotation. >>> >>> Attr.java:1482: ugly use of @SuppressWarnings. I understand why it is >>> there, >>> but it exemplifies why @Deprecated on the declaration is a bad idea. >>> It'll be too easy to not remove these annotations in JDK 13. >>> >>> Attr:1825: why XXX >>> >>> LambdaToMethod: unnecessary new import, CaseKind >>> Flow: unnecessary new import, CaseKind >>> >>> JavacParser: order of imports >>> >>> messages: generally, I think the text of the messages could be improved >>> (related but not new) we should somehow identify language keywords from >>> English text (i.e. words like `break, `case`, `continue`, `return`) >>> 204: saying the name is both a valid label and a valid expression hints >>> at the cause but not the error (i.e. the name is ambiguous) >>> >>> JCTree: inconsistent layout of annotations; inconsistent use of >>> @Deprecated and @Deprecated(forRemoval=true) >>> >>> (tests) >>> Not reviewed in detail yet. >>> New test descriptions should use "/*" for jtreg comment block; not >>> "/**". These are not javadoc documentation comments. >>> New test descriptions should have @summary >>> Presumably, we will have to change the -old.out files if the preview >>> feature becomes standard in JDK 13. >>> >>> >>> Overall, >>> >>> The logic is nice, but the use of @Deprecated(forRemoval=true) and >>> resulting @SuppressWarnings really suck. >>> I don't think the current practice is serving us well. >>> >>> -- Jon >>> >>> >>> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>>> Hi, >>>> >>>> As JEP 325 is in the proposed to target state, I thought it might be a >>>> good idea to start a review process for the code. >>>> >>>> The code here strives to implement the current specification for the >>>> Switch Expressions: >>>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>>> >>>> The current webrev is here: >>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>>> >>>> (includes a list of new errors.) >>>> >>>> JBS: >>>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>>> >>>> CSRs: >>>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>>> >>>> Any feedback is welcome! >>>> >>>> Thanks, >>>> Jan >>> > From maurizio.cimadamore at oracle.com Wed Aug 1 16:39:59 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 1 Aug 2018 17:39:59 +0100 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B61D51B.3070905@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> Message-ID: On 01/08/18 16:43, Jan Lahoda wrote: > Hi Maurizio, > > Thanks for the comments - responses are inlined. > > On 1.8.2018 16:04, Maurizio Cimadamore wrote: >> Hi Jan, >> great work, some comments below. >> >> * Diagnostics. I see that some diagnostics seem to be inconsistent with >> what we do for 'return' - e.g. javac diagnostics for 'return' are quite >> succint: >> >> - "return outside method" >> >> - "missing return statement" >> >> - "unexpected return value" >> >> - "error: incompatible types: String cannot be converted to int" >> >> The analogous conditions for break in switch expression seem to be more >> verbose: >> >> - "expression break not immediately enclosed by a switch expression" > > I think the closest error to "return outside method" is "value break > outside of switch expression". The "expression break not immediately > enclosed by a switch expression" is used when the break is inside > another breakable statement inside the switch expression. I guess this > should be rephrased at least to "value break not immediately enclosed > by switch expression". > Fine, but do we need two distinct errors? Or do we need maybe the same error and an extra detail string at the bottom for the 'you are inside a switch expr, but there's some other breaky context in between' condition? >> >> - "break is missing a value to return from switch expression" > > How about > "missing break value"? > > (the break is present, but the value is missing.) I'm fine with that! > >> >> - There's no equivalent for the third above - probably the closest >> condition would be to 'break expr' from a switch statement, in which >> case I bet you get a 'missing label' error - should we rectify that too? > > There are several conditions, and the error differ, consider: > --- > public class SwitchExpr { > ????? private void breakTest(int e) { > ????????? break ; > ????????? break x; > ????????? break (e); > ????????? while (true) { > ?????????????? break x; > ?????????????? break (e); > ????????? } > ????? } > } > --- > > This gives: > --- > SwitchExpr.java:3: error: break outside switch or loop > ????????? break ; > ????????? ^ > SwitchExpr.java:4: error: undefined label: x > ????????? break x; > ????????? ^ > SwitchExpr.java:5: error: value break outside of switch expression > ????????? break (e); > ????????? ^ > SwitchExpr.java:7: error: undefined label: x > ?????????????? break x; > ?????????????? ^ > SwitchExpr.java:8: error: value break outside of switch expression > ?????????????? break (e); > ?????????????? ^ > 5 errors > --- > > So when it is clear the break is a value break, a value break related > diagnostic is reported, otherwise, the errors fall back to the > existing diagnostics of cannot find labels. > >> >> - "incompatible types: bad type in switch expression" >> ... >> (A cannot be converted to B) > > I think this was modelled based on conditional expressions: > SwitchExpr.java:10: error: incompatible types: bad type in conditional > expression > ????????? B b = e == 0 ? (A) null : (B) null; > ???????????????????????? ^ > ??? A cannot be converted to B > > I'll look if this can be changed. I see, I'm not a big fan of the conditional expression nesting too - I think the important part is 'A != B' and it should be put front and center. That said, this is not a blocking issue, and I'm ok with a followup. > >> >> Not sure whether we should try to maintain the same style across >> break/return, but it seemed worth at least pointing out. >> >> Other diagnostic comments: >> >> - "error: j is ambiguously both a valid expression and a valid label" - >> this seems convoluted, I would personally rephrase as something like: >> >> ambiguous reference to 'j' >> ... >> ('j' is both a label and an expression) > > Will done. > >> >> - "break is jumping outside of the enclosing switch expression" -> >> "break outside of enclosing switch expression" > > Will do. > >> >> - "continue is jumping outside of the enclosing switch expression" -> >> "continue outside of enclosing switch expression" > > Will do. > >> >> * Attr - The refactoring of switchExpr into switch + handleSwitch is >> very sweet - I like it! >> >> * Flow - a bit odd that we have to make up a new tree to call recordExit >> - but I see why you're doing it :-) >> >> * Lower - it would be nice to have a comment on SwitchExpression that >> shows what the generated code shape looks like; I think we do that for >> other non-trivial translations (e.g. for each) > > Will do. Thanks Maurizio > > Thanks, > ??? Jan > >> >> * ExpSwitchNestingTest - I see that this test is not using the newer >> combo framework. Actually, I'm not even sure this one needs any >> templating logic at all, as it seems the test is doing its own >> replacements. But I was going to note that this test is not using the >> shared context enhancements, which I guess it's still ok given the >> number of combinations checked is low. Maybe worth keeping an eye on >> this in the future, should we keep adding new cases to it. >> >> Maurizio >> >> On 01/08/18 07:28, Jan Lahoda wrote: >>> Hi Jon, >>> >>> Thanks for the comments! >>> >>> An updated webrev that reflects the comments is here: >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ >>> >>> A delta webrev between this webrev and the webrev.00 is here: >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ >>> >>> Does this look better? >>> >>> Thanks! >>> >>> Jan >>> >>> On 28.7.2018 01:12, Jonathan Gibbons wrote: >>>> CaseTree.java:52: spelling, "lables" >>>> >>>> CaseTree.java:84:? "return" should be "returns". >>>> >>>> Lots of @Deprecated annotations without corresponding @deprecated >>>> javadoc tag. >>>> Should the @apiNote really be @deprecated.? I also think that using >>>> @Deprecated >>>> like this is "a bit smelly", and had a discussion with Stuart "Dr >>>> Deprecator" regarding >>>> my concerns. If nothing else, assuming the feature is a success, we >>>> are >>>> setting up >>>> a precedent of marking an API as deprecated-for-removal, and then >>>> in the >>>> next >>>> release, simply removing the annotation. >>>> >>>> Attr.java:1482: ugly use of @SuppressWarnings. I understand why it is >>>> there, >>>> but it exemplifies why @Deprecated on the declaration is a bad idea. >>>> It'll be too easy to not remove these annotations in JDK 13. >>>> >>>> Attr:1825: why XXX >>>> >>>> LambdaToMethod: unnecessary new import, CaseKind >>>> Flow: unnecessary new import, CaseKind >>>> >>>> JavacParser: order of imports >>>> >>>> messages: generally, I think the text of the messages could be >>>> improved >>>> (related but not new) we should somehow identify language keywords >>>> from >>>> English text (i.e. words like `break, `case`, `continue`, `return`) >>>> 204: saying the name is both a valid label and a valid expression >>>> hints >>>> at the cause but not the error (i.e. the name is ambiguous) >>>> >>>> JCTree: inconsistent layout of annotations; inconsistent use of >>>> @Deprecated and @Deprecated(forRemoval=true) >>>> >>>> (tests) >>>> Not reviewed in detail yet. >>>> New test descriptions should use "/*" for jtreg comment block; not >>>> "/**". These are not javadoc documentation comments. >>>> New test descriptions should have @summary >>>> Presumably, we will have to change the -old.out files if the preview >>>> feature becomes standard in JDK 13. >>>> >>>> >>>> Overall, >>>> >>>> The logic is nice, but the use of @Deprecated(forRemoval=true) and >>>> resulting @SuppressWarnings really suck. >>>> I don't think the current practice is serving us well. >>>> >>>> -- Jon >>>> >>>> >>>> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> As JEP 325 is in the proposed to target state, I thought it might >>>>> be a >>>>> good idea to start a review process for the code. >>>>> >>>>> The code here strives to implement the current specification for the >>>>> Switch Expressions: >>>>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>>>> >>>>> The current webrev is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>>>> >>>>> (includes a list of new errors.) >>>>> >>>>> JBS: >>>>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>>>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>>>> >>>>> CSRs: >>>>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>>>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>>>> >>>>> Any feedback is welcome! >>>>> >>>>> Thanks, >>>>> ??? Jan >>>> >> From jan.lahoda at oracle.com Fri Aug 3 13:35:04 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 3 Aug 2018 15:35:04 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> Message-ID: <5B645A08.50601@oracle.com> Hi, Thanks for all the comments. An updated patch is here: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/ Changes against the previous revision: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.01.02/ Updated specdiff: http://cr.openjdk.java.net/~jlahoda/8192963/api.diff.02/overview-summary.html Any feedback is welcome. Thanks, Jan On 1.8.2018 18:39, Maurizio Cimadamore wrote: > > > On 01/08/18 16:43, Jan Lahoda wrote: >> Hi Maurizio, >> >> Thanks for the comments - responses are inlined. >> >> On 1.8.2018 16:04, Maurizio Cimadamore wrote: >>> Hi Jan, >>> great work, some comments below. >>> >>> * Diagnostics. I see that some diagnostics seem to be inconsistent with >>> what we do for 'return' - e.g. javac diagnostics for 'return' are quite >>> succint: >>> >>> - "return outside method" >>> >>> - "missing return statement" >>> >>> - "unexpected return value" >>> >>> - "error: incompatible types: String cannot be converted to int" >>> >>> The analogous conditions for break in switch expression seem to be more >>> verbose: >>> >>> - "expression break not immediately enclosed by a switch expression" >> >> I think the closest error to "return outside method" is "value break >> outside of switch expression". The "expression break not immediately >> enclosed by a switch expression" is used when the break is inside >> another breakable statement inside the switch expression. I guess this >> should be rephrased at least to "value break not immediately enclosed >> by switch expression". >> > Fine, but do we need two distinct errors? Or do we need maybe the same > error and an extra detail string at the bottom for the 'you are inside a > switch expr, but there's some other breaky context in between' condition? >>> >>> - "break is missing a value to return from switch expression" >> >> How about >> "missing break value"? >> >> (the break is present, but the value is missing.) > I'm fine with that! >> >>> >>> - There's no equivalent for the third above - probably the closest >>> condition would be to 'break expr' from a switch statement, in which >>> case I bet you get a 'missing label' error - should we rectify that too? >> >> There are several conditions, and the error differ, consider: >> --- >> public class SwitchExpr { >> private void breakTest(int e) { >> break ; >> break x; >> break (e); >> while (true) { >> break x; >> break (e); >> } >> } >> } >> --- >> >> This gives: >> --- >> SwitchExpr.java:3: error: break outside switch or loop >> break ; >> ^ >> SwitchExpr.java:4: error: undefined label: x >> break x; >> ^ >> SwitchExpr.java:5: error: value break outside of switch expression >> break (e); >> ^ >> SwitchExpr.java:7: error: undefined label: x >> break x; >> ^ >> SwitchExpr.java:8: error: value break outside of switch expression >> break (e); >> ^ >> 5 errors >> --- >> >> So when it is clear the break is a value break, a value break related >> diagnostic is reported, otherwise, the errors fall back to the >> existing diagnostics of cannot find labels. >> >>> >>> - "incompatible types: bad type in switch expression" >>> ... >>> (A cannot be converted to B) >> >> I think this was modelled based on conditional expressions: >> SwitchExpr.java:10: error: incompatible types: bad type in conditional >> expression >> B b = e == 0 ? (A) null : (B) null; >> ^ >> A cannot be converted to B >> >> I'll look if this can be changed. > I see, I'm not a big fan of the conditional expression nesting too - I > think the important part is 'A != B' and it should be put front and > center. That said, this is not a blocking issue, and I'm ok with a > followup. >> >>> >>> Not sure whether we should try to maintain the same style across >>> break/return, but it seemed worth at least pointing out. >>> >>> Other diagnostic comments: >>> >>> - "error: j is ambiguously both a valid expression and a valid label" - >>> this seems convoluted, I would personally rephrase as something like: >>> >>> ambiguous reference to 'j' >>> ... >>> ('j' is both a label and an expression) >> >> Will done. >> >>> >>> - "break is jumping outside of the enclosing switch expression" -> >>> "break outside of enclosing switch expression" >> >> Will do. >> >>> >>> - "continue is jumping outside of the enclosing switch expression" -> >>> "continue outside of enclosing switch expression" >> >> Will do. >> >>> >>> * Attr - The refactoring of switchExpr into switch + handleSwitch is >>> very sweet - I like it! >>> >>> * Flow - a bit odd that we have to make up a new tree to call recordExit >>> - but I see why you're doing it :-) >>> >>> * Lower - it would be nice to have a comment on SwitchExpression that >>> shows what the generated code shape looks like; I think we do that for >>> other non-trivial translations (e.g. for each) >> >> Will do. > Thanks > Maurizio >> >> Thanks, >> Jan >> >>> >>> * ExpSwitchNestingTest - I see that this test is not using the newer >>> combo framework. Actually, I'm not even sure this one needs any >>> templating logic at all, as it seems the test is doing its own >>> replacements. But I was going to note that this test is not using the >>> shared context enhancements, which I guess it's still ok given the >>> number of combinations checked is low. Maybe worth keeping an eye on >>> this in the future, should we keep adding new cases to it. >>> >>> Maurizio >>> >>> On 01/08/18 07:28, Jan Lahoda wrote: >>>> Hi Jon, >>>> >>>> Thanks for the comments! >>>> >>>> An updated webrev that reflects the comments is here: >>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ >>>> >>>> A delta webrev between this webrev and the webrev.00 is here: >>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ >>>> >>>> Does this look better? >>>> >>>> Thanks! >>>> >>>> Jan >>>> >>>> On 28.7.2018 01:12, Jonathan Gibbons wrote: >>>>> CaseTree.java:52: spelling, "lables" >>>>> >>>>> CaseTree.java:84: "return" should be "returns". >>>>> >>>>> Lots of @Deprecated annotations without corresponding @deprecated >>>>> javadoc tag. >>>>> Should the @apiNote really be @deprecated. I also think that using >>>>> @Deprecated >>>>> like this is "a bit smelly", and had a discussion with Stuart "Dr >>>>> Deprecator" regarding >>>>> my concerns. If nothing else, assuming the feature is a success, we >>>>> are >>>>> setting up >>>>> a precedent of marking an API as deprecated-for-removal, and then >>>>> in the >>>>> next >>>>> release, simply removing the annotation. >>>>> >>>>> Attr.java:1482: ugly use of @SuppressWarnings. I understand why it is >>>>> there, >>>>> but it exemplifies why @Deprecated on the declaration is a bad idea. >>>>> It'll be too easy to not remove these annotations in JDK 13. >>>>> >>>>> Attr:1825: why XXX >>>>> >>>>> LambdaToMethod: unnecessary new import, CaseKind >>>>> Flow: unnecessary new import, CaseKind >>>>> >>>>> JavacParser: order of imports >>>>> >>>>> messages: generally, I think the text of the messages could be >>>>> improved >>>>> (related but not new) we should somehow identify language keywords >>>>> from >>>>> English text (i.e. words like `break, `case`, `continue`, `return`) >>>>> 204: saying the name is both a valid label and a valid expression >>>>> hints >>>>> at the cause but not the error (i.e. the name is ambiguous) >>>>> >>>>> JCTree: inconsistent layout of annotations; inconsistent use of >>>>> @Deprecated and @Deprecated(forRemoval=true) >>>>> >>>>> (tests) >>>>> Not reviewed in detail yet. >>>>> New test descriptions should use "/*" for jtreg comment block; not >>>>> "/**". These are not javadoc documentation comments. >>>>> New test descriptions should have @summary >>>>> Presumably, we will have to change the -old.out files if the preview >>>>> feature becomes standard in JDK 13. >>>>> >>>>> >>>>> Overall, >>>>> >>>>> The logic is nice, but the use of @Deprecated(forRemoval=true) and >>>>> resulting @SuppressWarnings really suck. >>>>> I don't think the current practice is serving us well. >>>>> >>>>> -- Jon >>>>> >>>>> >>>>> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> As JEP 325 is in the proposed to target state, I thought it might >>>>>> be a >>>>>> good idea to start a review process for the code. >>>>>> >>>>>> The code here strives to implement the current specification for the >>>>>> Switch Expressions: >>>>>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>>>>> >>>>>> The current webrev is here: >>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>>>>> >>>>>> (includes a list of new errors.) >>>>>> >>>>>> JBS: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>>>>> >>>>>> CSRs: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>>>>> >>>>>> Any feedback is welcome! >>>>>> >>>>>> Thanks, >>>>>> Jan >>>>> >>> > From maurizio.cimadamore at oracle.com Fri Aug 3 13:47:50 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 3 Aug 2018 14:47:50 +0100 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B645A08.50601@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> Message-ID: <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> I like the diagnostic changes, and the API change - I think it's more consistent now - thanks for taking a second look. Thumbs up. Maurizio On 03/08/18 14:35, Jan Lahoda wrote: > Hi, > > Thanks for all the comments. An updated patch is here: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/ > Changes against the previous revision: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.01.02/ > > Updated specdiff: > http://cr.openjdk.java.net/~jlahoda/8192963/api.diff.02/overview-summary.html > > > Any feedback is welcome. > > Thanks, > ??? Jan > > On 1.8.2018 18:39, Maurizio Cimadamore wrote: >> >> >> On 01/08/18 16:43, Jan Lahoda wrote: >>> Hi Maurizio, >>> >>> Thanks for the comments - responses are inlined. >>> >>> On 1.8.2018 16:04, Maurizio Cimadamore wrote: >>>> Hi Jan, >>>> great work, some comments below. >>>> >>>> * Diagnostics. I see that some diagnostics seem to be inconsistent >>>> with >>>> what we do for 'return' - e.g. javac diagnostics for 'return' are >>>> quite >>>> succint: >>>> >>>> - "return outside method" >>>> >>>> - "missing return statement" >>>> >>>> - "unexpected return value" >>>> >>>> - "error: incompatible types: String cannot be converted to int" >>>> >>>> The analogous conditions for break in switch expression seem to be >>>> more >>>> verbose: >>>> >>>> - "expression break not immediately enclosed by a switch expression" >>> >>> I think the closest error to "return outside method" is "value break >>> outside of switch expression". The "expression break not immediately >>> enclosed by a switch expression" is used when the break is inside >>> another breakable statement inside the switch expression. I guess this >>> should be rephrased at least to "value break not immediately enclosed >>> by switch expression". >>> >> Fine, but do we need two distinct errors? Or do we need maybe the same >> error and an extra detail string at the bottom for the 'you are inside a >> switch expr, but there's some other breaky context in between' >> condition? >>>> >>>> - "break is missing a value to return from switch expression" >>> >>> How about >>> "missing break value"? >>> >>> (the break is present, but the value is missing.) >> I'm fine with that! >>> >>>> >>>> - There's no equivalent for the third above - probably the closest >>>> condition would be to 'break expr' from a switch statement, in which >>>> case I bet you get a 'missing label' error - should we rectify that >>>> too? >>> >>> There are several conditions, and the error differ, consider: >>> --- >>> public class SwitchExpr { >>> ????? private void breakTest(int e) { >>> ????????? break ; >>> ????????? break x; >>> ????????? break (e); >>> ????????? while (true) { >>> ?????????????? break x; >>> ?????????????? break (e); >>> ????????? } >>> ????? } >>> } >>> --- >>> >>> This gives: >>> --- >>> SwitchExpr.java:3: error: break outside switch or loop >>> ????????? break ; >>> ????????? ^ >>> SwitchExpr.java:4: error: undefined label: x >>> ????????? break x; >>> ????????? ^ >>> SwitchExpr.java:5: error: value break outside of switch expression >>> ????????? break (e); >>> ????????? ^ >>> SwitchExpr.java:7: error: undefined label: x >>> ?????????????? break x; >>> ?????????????? ^ >>> SwitchExpr.java:8: error: value break outside of switch expression >>> ?????????????? break (e); >>> ?????????????? ^ >>> 5 errors >>> --- >>> >>> So when it is clear the break is a value break, a value break related >>> diagnostic is reported, otherwise, the errors fall back to the >>> existing diagnostics of cannot find labels. >>> >>>> >>>> - "incompatible types: bad type in switch expression" >>>> ... >>>> (A cannot be converted to B) >>> >>> I think this was modelled based on conditional expressions: >>> SwitchExpr.java:10: error: incompatible types: bad type in conditional >>> expression >>> ????????? B b = e == 0 ? (A) null : (B) null; >>> ???????????????????????? ^ >>> ??? A cannot be converted to B >>> >>> I'll look if this can be changed. >> I see, I'm not a big fan of the conditional expression nesting too - I >> think the important part is 'A != B' and it should be put front and >> center. That said, this is not a blocking issue, and I'm ok with a >> followup. >>> >>>> >>>> Not sure whether we should try to maintain the same style across >>>> break/return, but it seemed worth at least pointing out. >>>> >>>> Other diagnostic comments: >>>> >>>> - "error: j is ambiguously both a valid expression and a valid >>>> label" - >>>> this seems convoluted, I would personally rephrase as something like: >>>> >>>> ambiguous reference to 'j' >>>> ... >>>> ('j' is both a label and an expression) >>> >>> Will done. >>> >>>> >>>> - "break is jumping outside of the enclosing switch expression" -> >>>> "break outside of enclosing switch expression" >>> >>> Will do. >>> >>>> >>>> - "continue is jumping outside of the enclosing switch expression" -> >>>> "continue outside of enclosing switch expression" >>> >>> Will do. >>> >>>> >>>> * Attr - The refactoring of switchExpr into switch + handleSwitch is >>>> very sweet - I like it! >>>> >>>> * Flow - a bit odd that we have to make up a new tree to call >>>> recordExit >>>> - but I see why you're doing it :-) >>>> >>>> * Lower - it would be nice to have a comment on SwitchExpression that >>>> shows what the generated code shape looks like; I think we do that for >>>> other non-trivial translations (e.g. for each) >>> >>> Will do. >> Thanks >> Maurizio >>> >>> Thanks, >>> ??? Jan >>> >>>> >>>> * ExpSwitchNestingTest - I see that this test is not using the newer >>>> combo framework. Actually, I'm not even sure this one needs any >>>> templating logic at all, as it seems the test is doing its own >>>> replacements. But I was going to note that this test is not using the >>>> shared context enhancements, which I guess it's still ok given the >>>> number of combinations checked is low. Maybe worth keeping an eye on >>>> this in the future, should we keep adding new cases to it. >>>> >>>> Maurizio >>>> >>>> On 01/08/18 07:28, Jan Lahoda wrote: >>>>> Hi Jon, >>>>> >>>>> Thanks for the comments! >>>>> >>>>> An updated webrev that reflects the comments is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ >>>>> >>>>> A delta webrev between this webrev and the webrev.00 is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ >>>>> >>>>> Does this look better? >>>>> >>>>> Thanks! >>>>> >>>>> Jan >>>>> >>>>> On 28.7.2018 01:12, Jonathan Gibbons wrote: >>>>>> CaseTree.java:52: spelling, "lables" >>>>>> >>>>>> CaseTree.java:84:? "return" should be "returns". >>>>>> >>>>>> Lots of @Deprecated annotations without corresponding @deprecated >>>>>> javadoc tag. >>>>>> Should the @apiNote really be @deprecated.? I also think that using >>>>>> @Deprecated >>>>>> like this is "a bit smelly", and had a discussion with Stuart "Dr >>>>>> Deprecator" regarding >>>>>> my concerns. If nothing else, assuming the feature is a success, we >>>>>> are >>>>>> setting up >>>>>> a precedent of marking an API as deprecated-for-removal, and then >>>>>> in the >>>>>> next >>>>>> release, simply removing the annotation. >>>>>> >>>>>> Attr.java:1482: ugly use of @SuppressWarnings. I understand why >>>>>> it is >>>>>> there, >>>>>> but it exemplifies why @Deprecated on the declaration is a bad idea. >>>>>> It'll be too easy to not remove these annotations in JDK 13. >>>>>> >>>>>> Attr:1825: why XXX >>>>>> >>>>>> LambdaToMethod: unnecessary new import, CaseKind >>>>>> Flow: unnecessary new import, CaseKind >>>>>> >>>>>> JavacParser: order of imports >>>>>> >>>>>> messages: generally, I think the text of the messages could be >>>>>> improved >>>>>> (related but not new) we should somehow identify language keywords >>>>>> from >>>>>> English text (i.e. words like `break, `case`, `continue`, `return`) >>>>>> 204: saying the name is both a valid label and a valid expression >>>>>> hints >>>>>> at the cause but not the error (i.e. the name is ambiguous) >>>>>> >>>>>> JCTree: inconsistent layout of annotations; inconsistent use of >>>>>> @Deprecated and @Deprecated(forRemoval=true) >>>>>> >>>>>> (tests) >>>>>> Not reviewed in detail yet. >>>>>> New test descriptions should use "/*" for jtreg comment block; not >>>>>> "/**". These are not javadoc documentation comments. >>>>>> New test descriptions should have @summary >>>>>> Presumably, we will have to change the -old.out files if the preview >>>>>> feature becomes standard in JDK 13. >>>>>> >>>>>> >>>>>> Overall, >>>>>> >>>>>> The logic is nice, but the use of @Deprecated(forRemoval=true) and >>>>>> resulting @SuppressWarnings really suck. >>>>>> I don't think the current practice is serving us well. >>>>>> >>>>>> -- Jon >>>>>> >>>>>> >>>>>> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> As JEP 325 is in the proposed to target state, I thought it might >>>>>>> be a >>>>>>> good idea to start a review process for the code. >>>>>>> >>>>>>> The code here strives to implement the current specification for >>>>>>> the >>>>>>> Switch Expressions: >>>>>>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>>>>>> >>>>>>> The current webrev is here: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>>>>>> >>>>>>> (includes a list of new errors.) >>>>>>> >>>>>>> JBS: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>>>>>> >>>>>>> CSRs: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>>>>>> >>>>>>> Any feedback is welcome! >>>>>>> >>>>>>> Thanks, >>>>>>> ??? Jan >>>>>> >>>> >> From jan.lahoda at oracle.com Fri Aug 3 14:22:36 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 3 Aug 2018 16:22:36 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> Message-ID: <5B64652C.5020000@oracle.com> On 3.8.2018 15:47, Maurizio Cimadamore wrote: > I like the diagnostic changes, and the API change - I think it's more > consistent now - thanks for taking a second look. Thanks! I've forgot to include the generated examples for this update, so I've placed it here: file:///usr/local/home/lahvac/src/jdk/cr.openjdk.java.net/8192963/webrev.02/diags.html Jan > > Thumbs up. > > Maurizio > > > On 03/08/18 14:35, Jan Lahoda wrote: >> Hi, >> >> Thanks for all the comments. An updated patch is here: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/ >> Changes against the previous revision: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.01.02/ >> >> Updated specdiff: >> http://cr.openjdk.java.net/~jlahoda/8192963/api.diff.02/overview-summary.html >> >> >> Any feedback is welcome. >> >> Thanks, >> Jan >> >> On 1.8.2018 18:39, Maurizio Cimadamore wrote: >>> >>> >>> On 01/08/18 16:43, Jan Lahoda wrote: >>>> Hi Maurizio, >>>> >>>> Thanks for the comments - responses are inlined. >>>> >>>> On 1.8.2018 16:04, Maurizio Cimadamore wrote: >>>>> Hi Jan, >>>>> great work, some comments below. >>>>> >>>>> * Diagnostics. I see that some diagnostics seem to be inconsistent >>>>> with >>>>> what we do for 'return' - e.g. javac diagnostics for 'return' are >>>>> quite >>>>> succint: >>>>> >>>>> - "return outside method" >>>>> >>>>> - "missing return statement" >>>>> >>>>> - "unexpected return value" >>>>> >>>>> - "error: incompatible types: String cannot be converted to int" >>>>> >>>>> The analogous conditions for break in switch expression seem to be >>>>> more >>>>> verbose: >>>>> >>>>> - "expression break not immediately enclosed by a switch expression" >>>> >>>> I think the closest error to "return outside method" is "value break >>>> outside of switch expression". The "expression break not immediately >>>> enclosed by a switch expression" is used when the break is inside >>>> another breakable statement inside the switch expression. I guess this >>>> should be rephrased at least to "value break not immediately enclosed >>>> by switch expression". >>>> >>> Fine, but do we need two distinct errors? Or do we need maybe the same >>> error and an extra detail string at the bottom for the 'you are inside a >>> switch expr, but there's some other breaky context in between' >>> condition? >>>>> >>>>> - "break is missing a value to return from switch expression" >>>> >>>> How about >>>> "missing break value"? >>>> >>>> (the break is present, but the value is missing.) >>> I'm fine with that! >>>> >>>>> >>>>> - There's no equivalent for the third above - probably the closest >>>>> condition would be to 'break expr' from a switch statement, in which >>>>> case I bet you get a 'missing label' error - should we rectify that >>>>> too? >>>> >>>> There are several conditions, and the error differ, consider: >>>> --- >>>> public class SwitchExpr { >>>> private void breakTest(int e) { >>>> break ; >>>> break x; >>>> break (e); >>>> while (true) { >>>> break x; >>>> break (e); >>>> } >>>> } >>>> } >>>> --- >>>> >>>> This gives: >>>> --- >>>> SwitchExpr.java:3: error: break outside switch or loop >>>> break ; >>>> ^ >>>> SwitchExpr.java:4: error: undefined label: x >>>> break x; >>>> ^ >>>> SwitchExpr.java:5: error: value break outside of switch expression >>>> break (e); >>>> ^ >>>> SwitchExpr.java:7: error: undefined label: x >>>> break x; >>>> ^ >>>> SwitchExpr.java:8: error: value break outside of switch expression >>>> break (e); >>>> ^ >>>> 5 errors >>>> --- >>>> >>>> So when it is clear the break is a value break, a value break related >>>> diagnostic is reported, otherwise, the errors fall back to the >>>> existing diagnostics of cannot find labels. >>>> >>>>> >>>>> - "incompatible types: bad type in switch expression" >>>>> ... >>>>> (A cannot be converted to B) >>>> >>>> I think this was modelled based on conditional expressions: >>>> SwitchExpr.java:10: error: incompatible types: bad type in conditional >>>> expression >>>> B b = e == 0 ? (A) null : (B) null; >>>> ^ >>>> A cannot be converted to B >>>> >>>> I'll look if this can be changed. >>> I see, I'm not a big fan of the conditional expression nesting too - I >>> think the important part is 'A != B' and it should be put front and >>> center. That said, this is not a blocking issue, and I'm ok with a >>> followup. >>>> >>>>> >>>>> Not sure whether we should try to maintain the same style across >>>>> break/return, but it seemed worth at least pointing out. >>>>> >>>>> Other diagnostic comments: >>>>> >>>>> - "error: j is ambiguously both a valid expression and a valid >>>>> label" - >>>>> this seems convoluted, I would personally rephrase as something like: >>>>> >>>>> ambiguous reference to 'j' >>>>> ... >>>>> ('j' is both a label and an expression) >>>> >>>> Will done. >>>> >>>>> >>>>> - "break is jumping outside of the enclosing switch expression" -> >>>>> "break outside of enclosing switch expression" >>>> >>>> Will do. >>>> >>>>> >>>>> - "continue is jumping outside of the enclosing switch expression" -> >>>>> "continue outside of enclosing switch expression" >>>> >>>> Will do. >>>> >>>>> >>>>> * Attr - The refactoring of switchExpr into switch + handleSwitch is >>>>> very sweet - I like it! >>>>> >>>>> * Flow - a bit odd that we have to make up a new tree to call >>>>> recordExit >>>>> - but I see why you're doing it :-) >>>>> >>>>> * Lower - it would be nice to have a comment on SwitchExpression that >>>>> shows what the generated code shape looks like; I think we do that for >>>>> other non-trivial translations (e.g. for each) >>>> >>>> Will do. >>> Thanks >>> Maurizio >>>> >>>> Thanks, >>>> Jan >>>> >>>>> >>>>> * ExpSwitchNestingTest - I see that this test is not using the newer >>>>> combo framework. Actually, I'm not even sure this one needs any >>>>> templating logic at all, as it seems the test is doing its own >>>>> replacements. But I was going to note that this test is not using the >>>>> shared context enhancements, which I guess it's still ok given the >>>>> number of combinations checked is low. Maybe worth keeping an eye on >>>>> this in the future, should we keep adding new cases to it. >>>>> >>>>> Maurizio >>>>> >>>>> On 01/08/18 07:28, Jan Lahoda wrote: >>>>>> Hi Jon, >>>>>> >>>>>> Thanks for the comments! >>>>>> >>>>>> An updated webrev that reflects the comments is here: >>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ >>>>>> >>>>>> A delta webrev between this webrev and the webrev.00 is here: >>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ >>>>>> >>>>>> Does this look better? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Jan >>>>>> >>>>>> On 28.7.2018 01:12, Jonathan Gibbons wrote: >>>>>>> CaseTree.java:52: spelling, "lables" >>>>>>> >>>>>>> CaseTree.java:84: "return" should be "returns". >>>>>>> >>>>>>> Lots of @Deprecated annotations without corresponding @deprecated >>>>>>> javadoc tag. >>>>>>> Should the @apiNote really be @deprecated. I also think that using >>>>>>> @Deprecated >>>>>>> like this is "a bit smelly", and had a discussion with Stuart "Dr >>>>>>> Deprecator" regarding >>>>>>> my concerns. If nothing else, assuming the feature is a success, we >>>>>>> are >>>>>>> setting up >>>>>>> a precedent of marking an API as deprecated-for-removal, and then >>>>>>> in the >>>>>>> next >>>>>>> release, simply removing the annotation. >>>>>>> >>>>>>> Attr.java:1482: ugly use of @SuppressWarnings. I understand why >>>>>>> it is >>>>>>> there, >>>>>>> but it exemplifies why @Deprecated on the declaration is a bad idea. >>>>>>> It'll be too easy to not remove these annotations in JDK 13. >>>>>>> >>>>>>> Attr:1825: why XXX >>>>>>> >>>>>>> LambdaToMethod: unnecessary new import, CaseKind >>>>>>> Flow: unnecessary new import, CaseKind >>>>>>> >>>>>>> JavacParser: order of imports >>>>>>> >>>>>>> messages: generally, I think the text of the messages could be >>>>>>> improved >>>>>>> (related but not new) we should somehow identify language keywords >>>>>>> from >>>>>>> English text (i.e. words like `break, `case`, `continue`, `return`) >>>>>>> 204: saying the name is both a valid label and a valid expression >>>>>>> hints >>>>>>> at the cause but not the error (i.e. the name is ambiguous) >>>>>>> >>>>>>> JCTree: inconsistent layout of annotations; inconsistent use of >>>>>>> @Deprecated and @Deprecated(forRemoval=true) >>>>>>> >>>>>>> (tests) >>>>>>> Not reviewed in detail yet. >>>>>>> New test descriptions should use "/*" for jtreg comment block; not >>>>>>> "/**". These are not javadoc documentation comments. >>>>>>> New test descriptions should have @summary >>>>>>> Presumably, we will have to change the -old.out files if the preview >>>>>>> feature becomes standard in JDK 13. >>>>>>> >>>>>>> >>>>>>> Overall, >>>>>>> >>>>>>> The logic is nice, but the use of @Deprecated(forRemoval=true) and >>>>>>> resulting @SuppressWarnings really suck. >>>>>>> I don't think the current practice is serving us well. >>>>>>> >>>>>>> -- Jon >>>>>>> >>>>>>> >>>>>>> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> As JEP 325 is in the proposed to target state, I thought it might >>>>>>>> be a >>>>>>>> good idea to start a review process for the code. >>>>>>>> >>>>>>>> The code here strives to implement the current specification for >>>>>>>> the >>>>>>>> Switch Expressions: >>>>>>>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>>>>>>> >>>>>>>> The current webrev is here: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>>>>>>> >>>>>>>> (includes a list of new errors.) >>>>>>>> >>>>>>>> JBS: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>>>>>>> >>>>>>>> CSRs: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>>>>>>> >>>>>>>> Any feedback is welcome! >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jan >>>>>>> >>>>> >>> > From jan.lahoda at oracle.com Fri Aug 3 20:26:34 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 3 Aug 2018 22:26:34 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B64652C.5020000@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> <5B64652C.5020000@oracle.com> Message-ID: <5B64BA7A.2010406@oracle.com> On 3.8.2018 16:22, Jan Lahoda wrote: > On 3.8.2018 15:47, Maurizio Cimadamore wrote: >> I like the diagnostic changes, and the API change - I think it's more >> consistent now - thanks for taking a second look. > > Thanks! > > I've forgot to include the generated examples for this update, so I've > placed it here: > file:///usr/local/home/lahvac/src/jdk/cr.openjdk.java.net/8192963/webrev.02/diags.html I apologize for a wrong link, the correct one is: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/diags.html Jan > > > Jan > >> >> Thumbs up. >> >> Maurizio >> >> >> On 03/08/18 14:35, Jan Lahoda wrote: >>> Hi, >>> >>> Thanks for all the comments. An updated patch is here: >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/ >>> Changes against the previous revision: >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.01.02/ >>> >>> Updated specdiff: >>> http://cr.openjdk.java.net/~jlahoda/8192963/api.diff.02/overview-summary.html >>> >>> >>> >>> Any feedback is welcome. >>> >>> Thanks, >>> Jan >>> >>> On 1.8.2018 18:39, Maurizio Cimadamore wrote: >>>> >>>> >>>> On 01/08/18 16:43, Jan Lahoda wrote: >>>>> Hi Maurizio, >>>>> >>>>> Thanks for the comments - responses are inlined. >>>>> >>>>> On 1.8.2018 16:04, Maurizio Cimadamore wrote: >>>>>> Hi Jan, >>>>>> great work, some comments below. >>>>>> >>>>>> * Diagnostics. I see that some diagnostics seem to be inconsistent >>>>>> with >>>>>> what we do for 'return' - e.g. javac diagnostics for 'return' are >>>>>> quite >>>>>> succint: >>>>>> >>>>>> - "return outside method" >>>>>> >>>>>> - "missing return statement" >>>>>> >>>>>> - "unexpected return value" >>>>>> >>>>>> - "error: incompatible types: String cannot be converted to int" >>>>>> >>>>>> The analogous conditions for break in switch expression seem to be >>>>>> more >>>>>> verbose: >>>>>> >>>>>> - "expression break not immediately enclosed by a switch expression" >>>>> >>>>> I think the closest error to "return outside method" is "value break >>>>> outside of switch expression". The "expression break not immediately >>>>> enclosed by a switch expression" is used when the break is inside >>>>> another breakable statement inside the switch expression. I guess this >>>>> should be rephrased at least to "value break not immediately enclosed >>>>> by switch expression". >>>>> >>>> Fine, but do we need two distinct errors? Or do we need maybe the same >>>> error and an extra detail string at the bottom for the 'you are >>>> inside a >>>> switch expr, but there's some other breaky context in between' >>>> condition? >>>>>> >>>>>> - "break is missing a value to return from switch expression" >>>>> >>>>> How about >>>>> "missing break value"? >>>>> >>>>> (the break is present, but the value is missing.) >>>> I'm fine with that! >>>>> >>>>>> >>>>>> - There's no equivalent for the third above - probably the closest >>>>>> condition would be to 'break expr' from a switch statement, in which >>>>>> case I bet you get a 'missing label' error - should we rectify that >>>>>> too? >>>>> >>>>> There are several conditions, and the error differ, consider: >>>>> --- >>>>> public class SwitchExpr { >>>>> private void breakTest(int e) { >>>>> break ; >>>>> break x; >>>>> break (e); >>>>> while (true) { >>>>> break x; >>>>> break (e); >>>>> } >>>>> } >>>>> } >>>>> --- >>>>> >>>>> This gives: >>>>> --- >>>>> SwitchExpr.java:3: error: break outside switch or loop >>>>> break ; >>>>> ^ >>>>> SwitchExpr.java:4: error: undefined label: x >>>>> break x; >>>>> ^ >>>>> SwitchExpr.java:5: error: value break outside of switch expression >>>>> break (e); >>>>> ^ >>>>> SwitchExpr.java:7: error: undefined label: x >>>>> break x; >>>>> ^ >>>>> SwitchExpr.java:8: error: value break outside of switch expression >>>>> break (e); >>>>> ^ >>>>> 5 errors >>>>> --- >>>>> >>>>> So when it is clear the break is a value break, a value break related >>>>> diagnostic is reported, otherwise, the errors fall back to the >>>>> existing diagnostics of cannot find labels. >>>>> >>>>>> >>>>>> - "incompatible types: bad type in switch expression" >>>>>> ... >>>>>> (A cannot be converted to B) >>>>> >>>>> I think this was modelled based on conditional expressions: >>>>> SwitchExpr.java:10: error: incompatible types: bad type in conditional >>>>> expression >>>>> B b = e == 0 ? (A) null : (B) null; >>>>> ^ >>>>> A cannot be converted to B >>>>> >>>>> I'll look if this can be changed. >>>> I see, I'm not a big fan of the conditional expression nesting too - I >>>> think the important part is 'A != B' and it should be put front and >>>> center. That said, this is not a blocking issue, and I'm ok with a >>>> followup. >>>>> >>>>>> >>>>>> Not sure whether we should try to maintain the same style across >>>>>> break/return, but it seemed worth at least pointing out. >>>>>> >>>>>> Other diagnostic comments: >>>>>> >>>>>> - "error: j is ambiguously both a valid expression and a valid >>>>>> label" - >>>>>> this seems convoluted, I would personally rephrase as something like: >>>>>> >>>>>> ambiguous reference to 'j' >>>>>> ... >>>>>> ('j' is both a label and an expression) >>>>> >>>>> Will done. >>>>> >>>>>> >>>>>> - "break is jumping outside of the enclosing switch expression" -> >>>>>> "break outside of enclosing switch expression" >>>>> >>>>> Will do. >>>>> >>>>>> >>>>>> - "continue is jumping outside of the enclosing switch expression" -> >>>>>> "continue outside of enclosing switch expression" >>>>> >>>>> Will do. >>>>> >>>>>> >>>>>> * Attr - The refactoring of switchExpr into switch + handleSwitch is >>>>>> very sweet - I like it! >>>>>> >>>>>> * Flow - a bit odd that we have to make up a new tree to call >>>>>> recordExit >>>>>> - but I see why you're doing it :-) >>>>>> >>>>>> * Lower - it would be nice to have a comment on SwitchExpression that >>>>>> shows what the generated code shape looks like; I think we do that >>>>>> for >>>>>> other non-trivial translations (e.g. for each) >>>>> >>>>> Will do. >>>> Thanks >>>> Maurizio >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>>>> >>>>>> * ExpSwitchNestingTest - I see that this test is not using the newer >>>>>> combo framework. Actually, I'm not even sure this one needs any >>>>>> templating logic at all, as it seems the test is doing its own >>>>>> replacements. But I was going to note that this test is not using the >>>>>> shared context enhancements, which I guess it's still ok given the >>>>>> number of combinations checked is low. Maybe worth keeping an eye on >>>>>> this in the future, should we keep adding new cases to it. >>>>>> >>>>>> Maurizio >>>>>> >>>>>> On 01/08/18 07:28, Jan Lahoda wrote: >>>>>>> Hi Jon, >>>>>>> >>>>>>> Thanks for the comments! >>>>>>> >>>>>>> An updated webrev that reflects the comments is here: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ >>>>>>> >>>>>>> A delta webrev between this webrev and the webrev.00 is here: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ >>>>>>> >>>>>>> Does this look better? >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>> On 28.7.2018 01:12, Jonathan Gibbons wrote: >>>>>>>> CaseTree.java:52: spelling, "lables" >>>>>>>> >>>>>>>> CaseTree.java:84: "return" should be "returns". >>>>>>>> >>>>>>>> Lots of @Deprecated annotations without corresponding @deprecated >>>>>>>> javadoc tag. >>>>>>>> Should the @apiNote really be @deprecated. I also think that using >>>>>>>> @Deprecated >>>>>>>> like this is "a bit smelly", and had a discussion with Stuart "Dr >>>>>>>> Deprecator" regarding >>>>>>>> my concerns. If nothing else, assuming the feature is a success, we >>>>>>>> are >>>>>>>> setting up >>>>>>>> a precedent of marking an API as deprecated-for-removal, and then >>>>>>>> in the >>>>>>>> next >>>>>>>> release, simply removing the annotation. >>>>>>>> >>>>>>>> Attr.java:1482: ugly use of @SuppressWarnings. I understand why >>>>>>>> it is >>>>>>>> there, >>>>>>>> but it exemplifies why @Deprecated on the declaration is a bad >>>>>>>> idea. >>>>>>>> It'll be too easy to not remove these annotations in JDK 13. >>>>>>>> >>>>>>>> Attr:1825: why XXX >>>>>>>> >>>>>>>> LambdaToMethod: unnecessary new import, CaseKind >>>>>>>> Flow: unnecessary new import, CaseKind >>>>>>>> >>>>>>>> JavacParser: order of imports >>>>>>>> >>>>>>>> messages: generally, I think the text of the messages could be >>>>>>>> improved >>>>>>>> (related but not new) we should somehow identify language keywords >>>>>>>> from >>>>>>>> English text (i.e. words like `break, `case`, `continue`, `return`) >>>>>>>> 204: saying the name is both a valid label and a valid expression >>>>>>>> hints >>>>>>>> at the cause but not the error (i.e. the name is ambiguous) >>>>>>>> >>>>>>>> JCTree: inconsistent layout of annotations; inconsistent use of >>>>>>>> @Deprecated and @Deprecated(forRemoval=true) >>>>>>>> >>>>>>>> (tests) >>>>>>>> Not reviewed in detail yet. >>>>>>>> New test descriptions should use "/*" for jtreg comment block; not >>>>>>>> "/**". These are not javadoc documentation comments. >>>>>>>> New test descriptions should have @summary >>>>>>>> Presumably, we will have to change the -old.out files if the >>>>>>>> preview >>>>>>>> feature becomes standard in JDK 13. >>>>>>>> >>>>>>>> >>>>>>>> Overall, >>>>>>>> >>>>>>>> The logic is nice, but the use of @Deprecated(forRemoval=true) and >>>>>>>> resulting @SuppressWarnings really suck. >>>>>>>> I don't think the current practice is serving us well. >>>>>>>> >>>>>>>> -- Jon >>>>>>>> >>>>>>>> >>>>>>>> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> As JEP 325 is in the proposed to target state, I thought it might >>>>>>>>> be a >>>>>>>>> good idea to start a review process for the code. >>>>>>>>> >>>>>>>>> The code here strives to implement the current specification for >>>>>>>>> the >>>>>>>>> Switch Expressions: >>>>>>>>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>>>>>>>> >>>>>>>>> The current webrev is here: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>>>>>>>> >>>>>>>>> (includes a list of new errors.) >>>>>>>>> >>>>>>>>> JBS: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>>>>>>>> >>>>>>>>> CSRs: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>>>>>>>> >>>>>>>>> Any feedback is welcome! >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jan >>>>>>>> >>>>>> >>>> >> From maurizio.cimadamore at oracle.com Fri Aug 3 20:39:48 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 3 Aug 2018 21:39:48 +0100 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B64BA7A.2010406@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> <5B64652C.5020000@oracle.com> <5B64BA7A.2010406@oracle.com> Message-ID: <1d6b0189-89a0-7e41-4a04-967383e89400@oracle.com> Looks good - when I eyeballed compiler.properties earlier I missed this: "value break not supported in 'enhanced for' " I understand why you get 'enhanced for', not sure that adds value w.r.t. just 'for'. I don't have a strong opinion. Maurizio On 03/08/18 21:26, Jan Lahoda wrote: > On 3.8.2018 16:22, Jan Lahoda wrote: >> On 3.8.2018 15:47, Maurizio Cimadamore wrote: >>> I like the diagnostic changes, and the API change - I think it's more >>> consistent now - thanks for taking a second look. >> >> Thanks! >> >> I've forgot to include the generated examples for this update, so I've >> placed it here: >> file:///usr/local/home/lahvac/src/jdk/cr.openjdk.java.net/8192963/webrev.02/diags.html >> > > I apologize for a wrong link, the correct one is: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/diags.html > > Jan > >> >> >> Jan >> >>> >>> Thumbs up. >>> >>> Maurizio >>> >>> >>> On 03/08/18 14:35, Jan Lahoda wrote: >>>> Hi, >>>> >>>> Thanks for all the comments. An updated patch is here: >>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/ >>>> Changes against the previous revision: >>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.01.02/ >>>> >>>> Updated specdiff: >>>> http://cr.openjdk.java.net/~jlahoda/8192963/api.diff.02/overview-summary.html >>>> >>>> >>>> >>>> >>>> Any feedback is welcome. >>>> >>>> Thanks, >>>> ??? Jan >>>> >>>> On 1.8.2018 18:39, Maurizio Cimadamore wrote: >>>>> >>>>> >>>>> On 01/08/18 16:43, Jan Lahoda wrote: >>>>>> Hi Maurizio, >>>>>> >>>>>> Thanks for the comments - responses are inlined. >>>>>> >>>>>> On 1.8.2018 16:04, Maurizio Cimadamore wrote: >>>>>>> Hi Jan, >>>>>>> great work, some comments below. >>>>>>> >>>>>>> * Diagnostics. I see that some diagnostics seem to be inconsistent >>>>>>> with >>>>>>> what we do for 'return' - e.g. javac diagnostics for 'return' are >>>>>>> quite >>>>>>> succint: >>>>>>> >>>>>>> - "return outside method" >>>>>>> >>>>>>> - "missing return statement" >>>>>>> >>>>>>> - "unexpected return value" >>>>>>> >>>>>>> - "error: incompatible types: String cannot be converted to int" >>>>>>> >>>>>>> The analogous conditions for break in switch expression seem to be >>>>>>> more >>>>>>> verbose: >>>>>>> >>>>>>> - "expression break not immediately enclosed by a switch >>>>>>> expression" >>>>>> >>>>>> I think the closest error to "return outside method" is "value break >>>>>> outside of switch expression". The "expression break not immediately >>>>>> enclosed by a switch expression" is used when the break is inside >>>>>> another breakable statement inside the switch expression. I guess >>>>>> this >>>>>> should be rephrased at least to "value break not immediately >>>>>> enclosed >>>>>> by switch expression". >>>>>> >>>>> Fine, but do we need two distinct errors? Or do we need maybe the >>>>> same >>>>> error and an extra detail string at the bottom for the 'you are >>>>> inside a >>>>> switch expr, but there's some other breaky context in between' >>>>> condition? >>>>>>> >>>>>>> - "break is missing a value to return from switch expression" >>>>>> >>>>>> How about >>>>>> "missing break value"? >>>>>> >>>>>> (the break is present, but the value is missing.) >>>>> I'm fine with that! >>>>>> >>>>>>> >>>>>>> - There's no equivalent for the third above - probably the closest >>>>>>> condition would be to 'break expr' from a switch statement, in >>>>>>> which >>>>>>> case I bet you get a 'missing label' error - should we rectify that >>>>>>> too? >>>>>> >>>>>> There are several conditions, and the error differ, consider: >>>>>> --- >>>>>> public class SwitchExpr { >>>>>> ????? private void breakTest(int e) { >>>>>> ????????? break ; >>>>>> ????????? break x; >>>>>> ????????? break (e); >>>>>> ????????? while (true) { >>>>>> ?????????????? break x; >>>>>> ?????????????? break (e); >>>>>> ????????? } >>>>>> ????? } >>>>>> } >>>>>> --- >>>>>> >>>>>> This gives: >>>>>> --- >>>>>> SwitchExpr.java:3: error: break outside switch or loop >>>>>> ????????? break ; >>>>>> ????????? ^ >>>>>> SwitchExpr.java:4: error: undefined label: x >>>>>> ????????? break x; >>>>>> ????????? ^ >>>>>> SwitchExpr.java:5: error: value break outside of switch expression >>>>>> ????????? break (e); >>>>>> ????????? ^ >>>>>> SwitchExpr.java:7: error: undefined label: x >>>>>> ?????????????? break x; >>>>>> ?????????????? ^ >>>>>> SwitchExpr.java:8: error: value break outside of switch expression >>>>>> ?????????????? break (e); >>>>>> ?????????????? ^ >>>>>> 5 errors >>>>>> --- >>>>>> >>>>>> So when it is clear the break is a value break, a value break >>>>>> related >>>>>> diagnostic is reported, otherwise, the errors fall back to the >>>>>> existing diagnostics of cannot find labels. >>>>>> >>>>>>> >>>>>>> - "incompatible types: bad type in switch expression" >>>>>>> ... >>>>>>> (A cannot be converted to B) >>>>>> >>>>>> I think this was modelled based on conditional expressions: >>>>>> SwitchExpr.java:10: error: incompatible types: bad type in >>>>>> conditional >>>>>> expression >>>>>> ????????? B b = e == 0 ? (A) null : (B) null; >>>>>> ???????????????????????? ^ >>>>>> ??? A cannot be converted to B >>>>>> >>>>>> I'll look if this can be changed. >>>>> I see, I'm not a big fan of the conditional expression nesting too >>>>> - I >>>>> think the important part is 'A != B' and it should be put front and >>>>> center. That said, this is not a blocking issue, and I'm ok with a >>>>> followup. >>>>>> >>>>>>> >>>>>>> Not sure whether we should try to maintain the same style across >>>>>>> break/return, but it seemed worth at least pointing out. >>>>>>> >>>>>>> Other diagnostic comments: >>>>>>> >>>>>>> - "error: j is ambiguously both a valid expression and a valid >>>>>>> label" - >>>>>>> this seems convoluted, I would personally rephrase as something >>>>>>> like: >>>>>>> >>>>>>> ambiguous reference to 'j' >>>>>>> ... >>>>>>> ('j' is both a label and an expression) >>>>>> >>>>>> Will done. >>>>>> >>>>>>> >>>>>>> - "break is jumping outside of the enclosing switch expression" -> >>>>>>> "break outside of enclosing switch expression" >>>>>> >>>>>> Will do. >>>>>> >>>>>>> >>>>>>> - "continue is jumping outside of the enclosing switch >>>>>>> expression" -> >>>>>>> "continue outside of enclosing switch expression" >>>>>> >>>>>> Will do. >>>>>> >>>>>>> >>>>>>> * Attr - The refactoring of switchExpr into switch + >>>>>>> handleSwitch is >>>>>>> very sweet - I like it! >>>>>>> >>>>>>> * Flow - a bit odd that we have to make up a new tree to call >>>>>>> recordExit >>>>>>> - but I see why you're doing it :-) >>>>>>> >>>>>>> * Lower - it would be nice to have a comment on SwitchExpression >>>>>>> that >>>>>>> shows what the generated code shape looks like; I think we do that >>>>>>> for >>>>>>> other non-trivial translations (e.g. for each) >>>>>> >>>>>> Will do. >>>>> Thanks >>>>> Maurizio >>>>>> >>>>>> Thanks, >>>>>> ??? Jan >>>>>> >>>>>>> >>>>>>> * ExpSwitchNestingTest - I see that this test is not using the >>>>>>> newer >>>>>>> combo framework. Actually, I'm not even sure this one needs any >>>>>>> templating logic at all, as it seems the test is doing its own >>>>>>> replacements. But I was going to note that this test is not >>>>>>> using the >>>>>>> shared context enhancements, which I guess it's still ok given the >>>>>>> number of combinations checked is low. Maybe worth keeping an >>>>>>> eye on >>>>>>> this in the future, should we keep adding new cases to it. >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> On 01/08/18 07:28, Jan Lahoda wrote: >>>>>>>> Hi Jon, >>>>>>>> >>>>>>>> Thanks for the comments! >>>>>>>> >>>>>>>> An updated webrev that reflects the comments is here: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ >>>>>>>> >>>>>>>> A delta webrev between this webrev and the webrev.00 is here: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ >>>>>>>> >>>>>>>> Does this look better? >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Jan >>>>>>>> >>>>>>>> On 28.7.2018 01:12, Jonathan Gibbons wrote: >>>>>>>>> CaseTree.java:52: spelling, "lables" >>>>>>>>> >>>>>>>>> CaseTree.java:84:? "return" should be "returns". >>>>>>>>> >>>>>>>>> Lots of @Deprecated annotations without corresponding @deprecated >>>>>>>>> javadoc tag. >>>>>>>>> Should the @apiNote really be @deprecated.? I also think that >>>>>>>>> using >>>>>>>>> @Deprecated >>>>>>>>> like this is "a bit smelly", and had a discussion with Stuart "Dr >>>>>>>>> Deprecator" regarding >>>>>>>>> my concerns. If nothing else, assuming the feature is a >>>>>>>>> success, we >>>>>>>>> are >>>>>>>>> setting up >>>>>>>>> a precedent of marking an API as deprecated-for-removal, and then >>>>>>>>> in the >>>>>>>>> next >>>>>>>>> release, simply removing the annotation. >>>>>>>>> >>>>>>>>> Attr.java:1482: ugly use of @SuppressWarnings. I understand why >>>>>>>>> it is >>>>>>>>> there, >>>>>>>>> but it exemplifies why @Deprecated on the declaration is a bad >>>>>>>>> idea. >>>>>>>>> It'll be too easy to not remove these annotations in JDK 13. >>>>>>>>> >>>>>>>>> Attr:1825: why XXX >>>>>>>>> >>>>>>>>> LambdaToMethod: unnecessary new import, CaseKind >>>>>>>>> Flow: unnecessary new import, CaseKind >>>>>>>>> >>>>>>>>> JavacParser: order of imports >>>>>>>>> >>>>>>>>> messages: generally, I think the text of the messages could be >>>>>>>>> improved >>>>>>>>> (related but not new) we should somehow identify language >>>>>>>>> keywords >>>>>>>>> from >>>>>>>>> English text (i.e. words like `break, `case`, `continue`, >>>>>>>>> `return`) >>>>>>>>> 204: saying the name is both a valid label and a valid expression >>>>>>>>> hints >>>>>>>>> at the cause but not the error (i.e. the name is ambiguous) >>>>>>>>> >>>>>>>>> JCTree: inconsistent layout of annotations; inconsistent use of >>>>>>>>> @Deprecated and @Deprecated(forRemoval=true) >>>>>>>>> >>>>>>>>> (tests) >>>>>>>>> Not reviewed in detail yet. >>>>>>>>> New test descriptions should use "/*" for jtreg comment block; >>>>>>>>> not >>>>>>>>> "/**". These are not javadoc documentation comments. >>>>>>>>> New test descriptions should have @summary >>>>>>>>> Presumably, we will have to change the -old.out files if the >>>>>>>>> preview >>>>>>>>> feature becomes standard in JDK 13. >>>>>>>>> >>>>>>>>> >>>>>>>>> Overall, >>>>>>>>> >>>>>>>>> The logic is nice, but the use of @Deprecated(forRemoval=true) >>>>>>>>> and >>>>>>>>> resulting @SuppressWarnings really suck. >>>>>>>>> I don't think the current practice is serving us well. >>>>>>>>> >>>>>>>>> -- Jon >>>>>>>>> >>>>>>>>> >>>>>>>>> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> As JEP 325 is in the proposed to target state, I thought it >>>>>>>>>> might >>>>>>>>>> be a >>>>>>>>>> good idea to start a review process for the code. >>>>>>>>>> >>>>>>>>>> The code here strives to implement the current specification for >>>>>>>>>> the >>>>>>>>>> Switch Expressions: >>>>>>>>>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>>>>>>>>> >>>>>>>>>> The current webrev is here: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>>>>>>>>> >>>>>>>>>> (includes a list of new errors.) >>>>>>>>>> >>>>>>>>>> JBS: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>>>>>>>>> >>>>>>>>>> CSRs: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>>>>>>>>> >>>>>>>>>> Any feedback is welcome! >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> ??? Jan >>>>>>>>> >>>>>>> >>>>> >>> From maurizio.cimadamore at oracle.com Tue Aug 7 11:21:55 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 7 Aug 2018 12:21:55 +0100 Subject: RFR 8209064: Make intellij support more robust after changes for 2018.2 Message-ID: <63022bb6-5a5e-8b34-b73f-a7f7a368f8f4@oracle.com> Hi, last week I submitted an 'emergency' patch to fix intellij project support after 2018.2 changes. The goal of these changes was to move the build.xml ant file out of the .idea folder, as the IDE no longer supported DOM indexing in such folders (as a result of https://youtrack.jetbrains.com/issue/IDEA-189915). As a workaround, I tweaked the scripts to copy build.xml in the build folder. Thinking more about this issue, there's a more robust fix possible, which doesn't involve moving files to the build folder (which could be potentially unreliable, depending on how people build the JDK). In fact, the best solution is to leave build.xml where it is, and fix the remaining configuration files to point at it. This allows to revert all changes in the scripts that set up the project configuration (bin/idea.sh for JDK, and make/langtools/build.xml for langtools). For the langtools project a bit more changes were necessary, given that in langtools we did not have a 'template' folder - and all intellij files were dumped onto the same path. So I had to move the configuration langtools files (all but build.xml) under a new template folder (located under make/langtools/intellij/make) and place build.xml outside it. Then tweak the build.xml script to work off this new template folder. These are all small conceptual changes, but the impact on the webrev is quite biggie (because of file renaming etc.). I also took the chance to fix some issues with the JDK project ANT configuration (see changes in make/idea/template/workspace.xml), as the last changes did not update the location of the ant file used here - as a result no ant target entries were showing up under the Build menu. Webrev here: http://cr.openjdk.java.net/~mcimadamore/8209064/ Cheers Maurizio From jan.lahoda at oracle.com Thu Aug 9 11:39:21 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 9 Aug 2018 13:39:21 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <1d6b0189-89a0-7e41-4a04-967383e89400@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> <5B64652C.5020000@oracle.com> <5B64BA7A.2010406@oracle.com> <1d6b0189-89a0-7e41-4a04-967383e89400@oracle.com> Message-ID: <5B6C27E9.9050902@oracle.com> On 3.8.2018 22:39, Maurizio Cimadamore wrote: > Looks good - when I eyeballed compiler.properties earlier I missed this: > > "value break not supported in 'enhanced for' " > > I understand why you get 'enhanced for', not sure that adds value w.r.t. > just 'for'. I don't have a strong opinion. Sounds reasonable, I've updated the compiler.properties, and added one more test for SimpleTreeVisitor. An updated patch is here: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.03/ delta from the previous revision: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.02.03/ Diagnostics: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.03/diags.html Thanks, Jan > > Maurizio > > > On 03/08/18 21:26, Jan Lahoda wrote: >> On 3.8.2018 16:22, Jan Lahoda wrote: >>> On 3.8.2018 15:47, Maurizio Cimadamore wrote: >>>> I like the diagnostic changes, and the API change - I think it's more >>>> consistent now - thanks for taking a second look. >>> >>> Thanks! >>> >>> I've forgot to include the generated examples for this update, so I've >>> placed it here: >>> file:///usr/local/home/lahvac/src/jdk/cr.openjdk.java.net/8192963/webrev.02/diags.html >>> >> >> I apologize for a wrong link, the correct one is: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/diags.html >> >> Jan >> >>> >>> >>> Jan >>> >>>> >>>> Thumbs up. >>>> >>>> Maurizio >>>> >>>> >>>> On 03/08/18 14:35, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> Thanks for all the comments. An updated patch is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/ >>>>> Changes against the previous revision: >>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.01.02/ >>>>> >>>>> Updated specdiff: >>>>> http://cr.openjdk.java.net/~jlahoda/8192963/api.diff.02/overview-summary.html >>>>> >>>>> >>>>> >>>>> >>>>> Any feedback is welcome. >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>>> On 1.8.2018 18:39, Maurizio Cimadamore wrote: >>>>>> >>>>>> >>>>>> On 01/08/18 16:43, Jan Lahoda wrote: >>>>>>> Hi Maurizio, >>>>>>> >>>>>>> Thanks for the comments - responses are inlined. >>>>>>> >>>>>>> On 1.8.2018 16:04, Maurizio Cimadamore wrote: >>>>>>>> Hi Jan, >>>>>>>> great work, some comments below. >>>>>>>> >>>>>>>> * Diagnostics. I see that some diagnostics seem to be inconsistent >>>>>>>> with >>>>>>>> what we do for 'return' - e.g. javac diagnostics for 'return' are >>>>>>>> quite >>>>>>>> succint: >>>>>>>> >>>>>>>> - "return outside method" >>>>>>>> >>>>>>>> - "missing return statement" >>>>>>>> >>>>>>>> - "unexpected return value" >>>>>>>> >>>>>>>> - "error: incompatible types: String cannot be converted to int" >>>>>>>> >>>>>>>> The analogous conditions for break in switch expression seem to be >>>>>>>> more >>>>>>>> verbose: >>>>>>>> >>>>>>>> - "expression break not immediately enclosed by a switch >>>>>>>> expression" >>>>>>> >>>>>>> I think the closest error to "return outside method" is "value break >>>>>>> outside of switch expression". The "expression break not immediately >>>>>>> enclosed by a switch expression" is used when the break is inside >>>>>>> another breakable statement inside the switch expression. I guess >>>>>>> this >>>>>>> should be rephrased at least to "value break not immediately >>>>>>> enclosed >>>>>>> by switch expression". >>>>>>> >>>>>> Fine, but do we need two distinct errors? Or do we need maybe the >>>>>> same >>>>>> error and an extra detail string at the bottom for the 'you are >>>>>> inside a >>>>>> switch expr, but there's some other breaky context in between' >>>>>> condition? >>>>>>>> >>>>>>>> - "break is missing a value to return from switch expression" >>>>>>> >>>>>>> How about >>>>>>> "missing break value"? >>>>>>> >>>>>>> (the break is present, but the value is missing.) >>>>>> I'm fine with that! >>>>>>> >>>>>>>> >>>>>>>> - There's no equivalent for the third above - probably the closest >>>>>>>> condition would be to 'break expr' from a switch statement, in >>>>>>>> which >>>>>>>> case I bet you get a 'missing label' error - should we rectify that >>>>>>>> too? >>>>>>> >>>>>>> There are several conditions, and the error differ, consider: >>>>>>> --- >>>>>>> public class SwitchExpr { >>>>>>> private void breakTest(int e) { >>>>>>> break ; >>>>>>> break x; >>>>>>> break (e); >>>>>>> while (true) { >>>>>>> break x; >>>>>>> break (e); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> --- >>>>>>> >>>>>>> This gives: >>>>>>> --- >>>>>>> SwitchExpr.java:3: error: break outside switch or loop >>>>>>> break ; >>>>>>> ^ >>>>>>> SwitchExpr.java:4: error: undefined label: x >>>>>>> break x; >>>>>>> ^ >>>>>>> SwitchExpr.java:5: error: value break outside of switch expression >>>>>>> break (e); >>>>>>> ^ >>>>>>> SwitchExpr.java:7: error: undefined label: x >>>>>>> break x; >>>>>>> ^ >>>>>>> SwitchExpr.java:8: error: value break outside of switch expression >>>>>>> break (e); >>>>>>> ^ >>>>>>> 5 errors >>>>>>> --- >>>>>>> >>>>>>> So when it is clear the break is a value break, a value break >>>>>>> related >>>>>>> diagnostic is reported, otherwise, the errors fall back to the >>>>>>> existing diagnostics of cannot find labels. >>>>>>> >>>>>>>> >>>>>>>> - "incompatible types: bad type in switch expression" >>>>>>>> ... >>>>>>>> (A cannot be converted to B) >>>>>>> >>>>>>> I think this was modelled based on conditional expressions: >>>>>>> SwitchExpr.java:10: error: incompatible types: bad type in >>>>>>> conditional >>>>>>> expression >>>>>>> B b = e == 0 ? (A) null : (B) null; >>>>>>> ^ >>>>>>> A cannot be converted to B >>>>>>> >>>>>>> I'll look if this can be changed. >>>>>> I see, I'm not a big fan of the conditional expression nesting too >>>>>> - I >>>>>> think the important part is 'A != B' and it should be put front and >>>>>> center. That said, this is not a blocking issue, and I'm ok with a >>>>>> followup. >>>>>>> >>>>>>>> >>>>>>>> Not sure whether we should try to maintain the same style across >>>>>>>> break/return, but it seemed worth at least pointing out. >>>>>>>> >>>>>>>> Other diagnostic comments: >>>>>>>> >>>>>>>> - "error: j is ambiguously both a valid expression and a valid >>>>>>>> label" - >>>>>>>> this seems convoluted, I would personally rephrase as something >>>>>>>> like: >>>>>>>> >>>>>>>> ambiguous reference to 'j' >>>>>>>> ... >>>>>>>> ('j' is both a label and an expression) >>>>>>> >>>>>>> Will done. >>>>>>> >>>>>>>> >>>>>>>> - "break is jumping outside of the enclosing switch expression" -> >>>>>>>> "break outside of enclosing switch expression" >>>>>>> >>>>>>> Will do. >>>>>>> >>>>>>>> >>>>>>>> - "continue is jumping outside of the enclosing switch >>>>>>>> expression" -> >>>>>>>> "continue outside of enclosing switch expression" >>>>>>> >>>>>>> Will do. >>>>>>> >>>>>>>> >>>>>>>> * Attr - The refactoring of switchExpr into switch + >>>>>>>> handleSwitch is >>>>>>>> very sweet - I like it! >>>>>>>> >>>>>>>> * Flow - a bit odd that we have to make up a new tree to call >>>>>>>> recordExit >>>>>>>> - but I see why you're doing it :-) >>>>>>>> >>>>>>>> * Lower - it would be nice to have a comment on SwitchExpression >>>>>>>> that >>>>>>>> shows what the generated code shape looks like; I think we do that >>>>>>>> for >>>>>>>> other non-trivial translations (e.g. for each) >>>>>>> >>>>>>> Will do. >>>>>> Thanks >>>>>> Maurizio >>>>>>> >>>>>>> Thanks, >>>>>>> Jan >>>>>>> >>>>>>>> >>>>>>>> * ExpSwitchNestingTest - I see that this test is not using the >>>>>>>> newer >>>>>>>> combo framework. Actually, I'm not even sure this one needs any >>>>>>>> templating logic at all, as it seems the test is doing its own >>>>>>>> replacements. But I was going to note that this test is not >>>>>>>> using the >>>>>>>> shared context enhancements, which I guess it's still ok given the >>>>>>>> number of combinations checked is low. Maybe worth keeping an >>>>>>>> eye on >>>>>>>> this in the future, should we keep adding new cases to it. >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> On 01/08/18 07:28, Jan Lahoda wrote: >>>>>>>>> Hi Jon, >>>>>>>>> >>>>>>>>> Thanks for the comments! >>>>>>>>> >>>>>>>>> An updated webrev that reflects the comments is here: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ >>>>>>>>> >>>>>>>>> A delta webrev between this webrev and the webrev.00 is here: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ >>>>>>>>> >>>>>>>>> Does this look better? >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> Jan >>>>>>>>> >>>>>>>>> On 28.7.2018 01:12, Jonathan Gibbons wrote: >>>>>>>>>> CaseTree.java:52: spelling, "lables" >>>>>>>>>> >>>>>>>>>> CaseTree.java:84: "return" should be "returns". >>>>>>>>>> >>>>>>>>>> Lots of @Deprecated annotations without corresponding @deprecated >>>>>>>>>> javadoc tag. >>>>>>>>>> Should the @apiNote really be @deprecated. I also think that >>>>>>>>>> using >>>>>>>>>> @Deprecated >>>>>>>>>> like this is "a bit smelly", and had a discussion with Stuart "Dr >>>>>>>>>> Deprecator" regarding >>>>>>>>>> my concerns. If nothing else, assuming the feature is a >>>>>>>>>> success, we >>>>>>>>>> are >>>>>>>>>> setting up >>>>>>>>>> a precedent of marking an API as deprecated-for-removal, and then >>>>>>>>>> in the >>>>>>>>>> next >>>>>>>>>> release, simply removing the annotation. >>>>>>>>>> >>>>>>>>>> Attr.java:1482: ugly use of @SuppressWarnings. I understand why >>>>>>>>>> it is >>>>>>>>>> there, >>>>>>>>>> but it exemplifies why @Deprecated on the declaration is a bad >>>>>>>>>> idea. >>>>>>>>>> It'll be too easy to not remove these annotations in JDK 13. >>>>>>>>>> >>>>>>>>>> Attr:1825: why XXX >>>>>>>>>> >>>>>>>>>> LambdaToMethod: unnecessary new import, CaseKind >>>>>>>>>> Flow: unnecessary new import, CaseKind >>>>>>>>>> >>>>>>>>>> JavacParser: order of imports >>>>>>>>>> >>>>>>>>>> messages: generally, I think the text of the messages could be >>>>>>>>>> improved >>>>>>>>>> (related but not new) we should somehow identify language >>>>>>>>>> keywords >>>>>>>>>> from >>>>>>>>>> English text (i.e. words like `break, `case`, `continue`, >>>>>>>>>> `return`) >>>>>>>>>> 204: saying the name is both a valid label and a valid expression >>>>>>>>>> hints >>>>>>>>>> at the cause but not the error (i.e. the name is ambiguous) >>>>>>>>>> >>>>>>>>>> JCTree: inconsistent layout of annotations; inconsistent use of >>>>>>>>>> @Deprecated and @Deprecated(forRemoval=true) >>>>>>>>>> >>>>>>>>>> (tests) >>>>>>>>>> Not reviewed in detail yet. >>>>>>>>>> New test descriptions should use "/*" for jtreg comment block; >>>>>>>>>> not >>>>>>>>>> "/**". These are not javadoc documentation comments. >>>>>>>>>> New test descriptions should have @summary >>>>>>>>>> Presumably, we will have to change the -old.out files if the >>>>>>>>>> preview >>>>>>>>>> feature becomes standard in JDK 13. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Overall, >>>>>>>>>> >>>>>>>>>> The logic is nice, but the use of @Deprecated(forRemoval=true) >>>>>>>>>> and >>>>>>>>>> resulting @SuppressWarnings really suck. >>>>>>>>>> I don't think the current practice is serving us well. >>>>>>>>>> >>>>>>>>>> -- Jon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> As JEP 325 is in the proposed to target state, I thought it >>>>>>>>>>> might >>>>>>>>>>> be a >>>>>>>>>>> good idea to start a review process for the code. >>>>>>>>>>> >>>>>>>>>>> The code here strives to implement the current specification for >>>>>>>>>>> the >>>>>>>>>>> Switch Expressions: >>>>>>>>>>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>>>>>>>>>> >>>>>>>>>>> The current webrev is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> (includes a list of new errors.) >>>>>>>>>>> >>>>>>>>>>> JBS: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>>>>>>>>>> >>>>>>>>>>> CSRs: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>>>>>>>>>> >>>>>>>>>>> Any feedback is welcome! >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Jan >>>>>>>>>> >>>>>>>> >>>>>> >>>> > From jan.lahoda at oracle.com Thu Aug 9 11:59:17 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 9 Aug 2018 13:59:17 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B6C27E9.9050902@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> <5B64652C.5020000@oracle.com> <5B64BA7A.2010406@oracle.com> <1d6b0189-89a0-7e41-4a04-967383e89400@oracle.com> <5B6C27E9.9050902@oracle.com> Message-ID: <5B6C2C95.5080609@oracle.com> One more tiny change to tests to fix a failure on Windows (I apologize for not folding that into the previous update): webrev: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.04/ delta from previous (webrev.03): http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.03.04/ Thanks, Jan On 9.8.2018 13:39, Jan Lahoda wrote: > On 3.8.2018 22:39, Maurizio Cimadamore wrote: >> Looks good - when I eyeballed compiler.properties earlier I missed this: >> >> "value break not supported in 'enhanced for' " >> >> I understand why you get 'enhanced for', not sure that adds value w.r.t. >> just 'for'. I don't have a strong opinion. > > Sounds reasonable, I've updated the compiler.properties, and added one > more test for SimpleTreeVisitor. > > An updated patch is here: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.03/ > > delta from the previous revision: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.02.03/ > > Diagnostics: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.03/diags.html > > Thanks, > Jan > >> >> Maurizio >> >> >> On 03/08/18 21:26, Jan Lahoda wrote: >>> On 3.8.2018 16:22, Jan Lahoda wrote: >>>> On 3.8.2018 15:47, Maurizio Cimadamore wrote: >>>>> I like the diagnostic changes, and the API change - I think it's more >>>>> consistent now - thanks for taking a second look. >>>> >>>> Thanks! >>>> >>>> I've forgot to include the generated examples for this update, so I've >>>> placed it here: >>>> file:///usr/local/home/lahvac/src/jdk/cr.openjdk.java.net/8192963/webrev.02/diags.html >>>> >>>> >>> >>> I apologize for a wrong link, the correct one is: >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/diags.html >>> >>> Jan >>> >>>> >>>> >>>> Jan >>>> >>>>> >>>>> Thumbs up. >>>>> >>>>> Maurizio >>>>> >>>>> >>>>> On 03/08/18 14:35, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> Thanks for all the comments. An updated patch is here: >>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/ >>>>>> Changes against the previous revision: >>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.01.02/ >>>>>> >>>>>> Updated specdiff: >>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/api.diff.02/overview-summary.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Any feedback is welcome. >>>>>> >>>>>> Thanks, >>>>>> Jan >>>>>> >>>>>> On 1.8.2018 18:39, Maurizio Cimadamore wrote: >>>>>>> >>>>>>> >>>>>>> On 01/08/18 16:43, Jan Lahoda wrote: >>>>>>>> Hi Maurizio, >>>>>>>> >>>>>>>> Thanks for the comments - responses are inlined. >>>>>>>> >>>>>>>> On 1.8.2018 16:04, Maurizio Cimadamore wrote: >>>>>>>>> Hi Jan, >>>>>>>>> great work, some comments below. >>>>>>>>> >>>>>>>>> * Diagnostics. I see that some diagnostics seem to be inconsistent >>>>>>>>> with >>>>>>>>> what we do for 'return' - e.g. javac diagnostics for 'return' are >>>>>>>>> quite >>>>>>>>> succint: >>>>>>>>> >>>>>>>>> - "return outside method" >>>>>>>>> >>>>>>>>> - "missing return statement" >>>>>>>>> >>>>>>>>> - "unexpected return value" >>>>>>>>> >>>>>>>>> - "error: incompatible types: String cannot be converted to int" >>>>>>>>> >>>>>>>>> The analogous conditions for break in switch expression seem to be >>>>>>>>> more >>>>>>>>> verbose: >>>>>>>>> >>>>>>>>> - "expression break not immediately enclosed by a switch >>>>>>>>> expression" >>>>>>>> >>>>>>>> I think the closest error to "return outside method" is "value >>>>>>>> break >>>>>>>> outside of switch expression". The "expression break not >>>>>>>> immediately >>>>>>>> enclosed by a switch expression" is used when the break is inside >>>>>>>> another breakable statement inside the switch expression. I guess >>>>>>>> this >>>>>>>> should be rephrased at least to "value break not immediately >>>>>>>> enclosed >>>>>>>> by switch expression". >>>>>>>> >>>>>>> Fine, but do we need two distinct errors? Or do we need maybe the >>>>>>> same >>>>>>> error and an extra detail string at the bottom for the 'you are >>>>>>> inside a >>>>>>> switch expr, but there's some other breaky context in between' >>>>>>> condition? >>>>>>>>> >>>>>>>>> - "break is missing a value to return from switch expression" >>>>>>>> >>>>>>>> How about >>>>>>>> "missing break value"? >>>>>>>> >>>>>>>> (the break is present, but the value is missing.) >>>>>>> I'm fine with that! >>>>>>>> >>>>>>>>> >>>>>>>>> - There's no equivalent for the third above - probably the closest >>>>>>>>> condition would be to 'break expr' from a switch statement, in >>>>>>>>> which >>>>>>>>> case I bet you get a 'missing label' error - should we rectify >>>>>>>>> that >>>>>>>>> too? >>>>>>>> >>>>>>>> There are several conditions, and the error differ, consider: >>>>>>>> --- >>>>>>>> public class SwitchExpr { >>>>>>>> private void breakTest(int e) { >>>>>>>> break ; >>>>>>>> break x; >>>>>>>> break (e); >>>>>>>> while (true) { >>>>>>>> break x; >>>>>>>> break (e); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> --- >>>>>>>> >>>>>>>> This gives: >>>>>>>> --- >>>>>>>> SwitchExpr.java:3: error: break outside switch or loop >>>>>>>> break ; >>>>>>>> ^ >>>>>>>> SwitchExpr.java:4: error: undefined label: x >>>>>>>> break x; >>>>>>>> ^ >>>>>>>> SwitchExpr.java:5: error: value break outside of switch expression >>>>>>>> break (e); >>>>>>>> ^ >>>>>>>> SwitchExpr.java:7: error: undefined label: x >>>>>>>> break x; >>>>>>>> ^ >>>>>>>> SwitchExpr.java:8: error: value break outside of switch expression >>>>>>>> break (e); >>>>>>>> ^ >>>>>>>> 5 errors >>>>>>>> --- >>>>>>>> >>>>>>>> So when it is clear the break is a value break, a value break >>>>>>>> related >>>>>>>> diagnostic is reported, otherwise, the errors fall back to the >>>>>>>> existing diagnostics of cannot find labels. >>>>>>>> >>>>>>>>> >>>>>>>>> - "incompatible types: bad type in switch expression" >>>>>>>>> ... >>>>>>>>> (A cannot be converted to B) >>>>>>>> >>>>>>>> I think this was modelled based on conditional expressions: >>>>>>>> SwitchExpr.java:10: error: incompatible types: bad type in >>>>>>>> conditional >>>>>>>> expression >>>>>>>> B b = e == 0 ? (A) null : (B) null; >>>>>>>> ^ >>>>>>>> A cannot be converted to B >>>>>>>> >>>>>>>> I'll look if this can be changed. >>>>>>> I see, I'm not a big fan of the conditional expression nesting too >>>>>>> - I >>>>>>> think the important part is 'A != B' and it should be put front and >>>>>>> center. That said, this is not a blocking issue, and I'm ok with a >>>>>>> followup. >>>>>>>> >>>>>>>>> >>>>>>>>> Not sure whether we should try to maintain the same style across >>>>>>>>> break/return, but it seemed worth at least pointing out. >>>>>>>>> >>>>>>>>> Other diagnostic comments: >>>>>>>>> >>>>>>>>> - "error: j is ambiguously both a valid expression and a valid >>>>>>>>> label" - >>>>>>>>> this seems convoluted, I would personally rephrase as something >>>>>>>>> like: >>>>>>>>> >>>>>>>>> ambiguous reference to 'j' >>>>>>>>> ... >>>>>>>>> ('j' is both a label and an expression) >>>>>>>> >>>>>>>> Will done. >>>>>>>> >>>>>>>>> >>>>>>>>> - "break is jumping outside of the enclosing switch expression" -> >>>>>>>>> "break outside of enclosing switch expression" >>>>>>>> >>>>>>>> Will do. >>>>>>>> >>>>>>>>> >>>>>>>>> - "continue is jumping outside of the enclosing switch >>>>>>>>> expression" -> >>>>>>>>> "continue outside of enclosing switch expression" >>>>>>>> >>>>>>>> Will do. >>>>>>>> >>>>>>>>> >>>>>>>>> * Attr - The refactoring of switchExpr into switch + >>>>>>>>> handleSwitch is >>>>>>>>> very sweet - I like it! >>>>>>>>> >>>>>>>>> * Flow - a bit odd that we have to make up a new tree to call >>>>>>>>> recordExit >>>>>>>>> - but I see why you're doing it :-) >>>>>>>>> >>>>>>>>> * Lower - it would be nice to have a comment on SwitchExpression >>>>>>>>> that >>>>>>>>> shows what the generated code shape looks like; I think we do that >>>>>>>>> for >>>>>>>>> other non-trivial translations (e.g. for each) >>>>>>>> >>>>>>>> Will do. >>>>>>> Thanks >>>>>>> Maurizio >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jan >>>>>>>> >>>>>>>>> >>>>>>>>> * ExpSwitchNestingTest - I see that this test is not using the >>>>>>>>> newer >>>>>>>>> combo framework. Actually, I'm not even sure this one needs any >>>>>>>>> templating logic at all, as it seems the test is doing its own >>>>>>>>> replacements. But I was going to note that this test is not >>>>>>>>> using the >>>>>>>>> shared context enhancements, which I guess it's still ok given the >>>>>>>>> number of combinations checked is low. Maybe worth keeping an >>>>>>>>> eye on >>>>>>>>> this in the future, should we keep adding new cases to it. >>>>>>>>> >>>>>>>>> Maurizio >>>>>>>>> >>>>>>>>> On 01/08/18 07:28, Jan Lahoda wrote: >>>>>>>>>> Hi Jon, >>>>>>>>>> >>>>>>>>>> Thanks for the comments! >>>>>>>>>> >>>>>>>>>> An updated webrev that reflects the comments is here: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ >>>>>>>>>> >>>>>>>>>> A delta webrev between this webrev and the webrev.00 is here: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ >>>>>>>>>> >>>>>>>>>> Does this look better? >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>>> On 28.7.2018 01:12, Jonathan Gibbons wrote: >>>>>>>>>>> CaseTree.java:52: spelling, "lables" >>>>>>>>>>> >>>>>>>>>>> CaseTree.java:84: "return" should be "returns". >>>>>>>>>>> >>>>>>>>>>> Lots of @Deprecated annotations without corresponding >>>>>>>>>>> @deprecated >>>>>>>>>>> javadoc tag. >>>>>>>>>>> Should the @apiNote really be @deprecated. I also think that >>>>>>>>>>> using >>>>>>>>>>> @Deprecated >>>>>>>>>>> like this is "a bit smelly", and had a discussion with Stuart >>>>>>>>>>> "Dr >>>>>>>>>>> Deprecator" regarding >>>>>>>>>>> my concerns. If nothing else, assuming the feature is a >>>>>>>>>>> success, we >>>>>>>>>>> are >>>>>>>>>>> setting up >>>>>>>>>>> a precedent of marking an API as deprecated-for-removal, and >>>>>>>>>>> then >>>>>>>>>>> in the >>>>>>>>>>> next >>>>>>>>>>> release, simply removing the annotation. >>>>>>>>>>> >>>>>>>>>>> Attr.java:1482: ugly use of @SuppressWarnings. I understand why >>>>>>>>>>> it is >>>>>>>>>>> there, >>>>>>>>>>> but it exemplifies why @Deprecated on the declaration is a bad >>>>>>>>>>> idea. >>>>>>>>>>> It'll be too easy to not remove these annotations in JDK 13. >>>>>>>>>>> >>>>>>>>>>> Attr:1825: why XXX >>>>>>>>>>> >>>>>>>>>>> LambdaToMethod: unnecessary new import, CaseKind >>>>>>>>>>> Flow: unnecessary new import, CaseKind >>>>>>>>>>> >>>>>>>>>>> JavacParser: order of imports >>>>>>>>>>> >>>>>>>>>>> messages: generally, I think the text of the messages could be >>>>>>>>>>> improved >>>>>>>>>>> (related but not new) we should somehow identify language >>>>>>>>>>> keywords >>>>>>>>>>> from >>>>>>>>>>> English text (i.e. words like `break, `case`, `continue`, >>>>>>>>>>> `return`) >>>>>>>>>>> 204: saying the name is both a valid label and a valid >>>>>>>>>>> expression >>>>>>>>>>> hints >>>>>>>>>>> at the cause but not the error (i.e. the name is ambiguous) >>>>>>>>>>> >>>>>>>>>>> JCTree: inconsistent layout of annotations; inconsistent use of >>>>>>>>>>> @Deprecated and @Deprecated(forRemoval=true) >>>>>>>>>>> >>>>>>>>>>> (tests) >>>>>>>>>>> Not reviewed in detail yet. >>>>>>>>>>> New test descriptions should use "/*" for jtreg comment block; >>>>>>>>>>> not >>>>>>>>>>> "/**". These are not javadoc documentation comments. >>>>>>>>>>> New test descriptions should have @summary >>>>>>>>>>> Presumably, we will have to change the -old.out files if the >>>>>>>>>>> preview >>>>>>>>>>> feature becomes standard in JDK 13. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Overall, >>>>>>>>>>> >>>>>>>>>>> The logic is nice, but the use of @Deprecated(forRemoval=true) >>>>>>>>>>> and >>>>>>>>>>> resulting @SuppressWarnings really suck. >>>>>>>>>>> I don't think the current practice is serving us well. >>>>>>>>>>> >>>>>>>>>>> -- Jon >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> As JEP 325 is in the proposed to target state, I thought it >>>>>>>>>>>> might >>>>>>>>>>>> be a >>>>>>>>>>>> good idea to start a review process for the code. >>>>>>>>>>>> >>>>>>>>>>>> The code here strives to implement the current specification >>>>>>>>>>>> for >>>>>>>>>>>> the >>>>>>>>>>>> Switch Expressions: >>>>>>>>>>>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>>>>>>>>>>> >>>>>>>>>>>> The current webrev is here: >>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> (includes a list of new errors.) >>>>>>>>>>>> >>>>>>>>>>>> JBS: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>>>>>>>>>>> >>>>>>>>>>>> CSRs: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>>>>>>>>>>> >>>>>>>>>>>> Any feedback is welcome! >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Jan >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >> From maurizio.cimadamore at oracle.com Thu Aug 9 12:53:54 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 9 Aug 2018 13:53:54 +0100 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B6C2C95.5080609@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> <5B64652C.5020000@oracle.com> <5B64BA7A.2010406@oracle.com> <1d6b0189-89a0-7e41-4a04-967383e89400@oracle.com> <5B6C27E9.9050902@oracle.com> <5B6C2C95.5080609@oracle.com> Message-ID: <3d8d27b0-7bfc-2c26-17b4-53b8bf2abf20@oracle.com> Looks good. Maurizio On 09/08/18 12:59, Jan Lahoda wrote: > One more tiny change to tests to fix a failure on Windows (I apologize > for not folding that into the previous update): > webrev: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.04/ > delta from previous (webrev.03): > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.03.04/ > > Thanks, > ??? Jan > > On 9.8.2018 13:39, Jan Lahoda wrote: >> On 3.8.2018 22:39, Maurizio Cimadamore wrote: >>> Looks good - when I eyeballed compiler.properties earlier I missed >>> this: >>> >>> "value break not supported in 'enhanced for' " >>> >>> I understand why you get 'enhanced for', not sure that adds value >>> w.r.t. >>> just 'for'. I don't have a strong opinion. >> >> Sounds reasonable, I've updated the compiler.properties, and added one >> more test for SimpleTreeVisitor. >> >> An updated patch is here: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.03/ >> >> delta from the previous revision: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.02.03/ >> >> Diagnostics: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.03/diags.html >> >> Thanks, >> ???? Jan >> >>> >>> Maurizio >>> >>> >>> On 03/08/18 21:26, Jan Lahoda wrote: >>>> On 3.8.2018 16:22, Jan Lahoda wrote: >>>>> On 3.8.2018 15:47, Maurizio Cimadamore wrote: >>>>>> I like the diagnostic changes, and the API change - I think it's >>>>>> more >>>>>> consistent now - thanks for taking a second look. >>>>> >>>>> Thanks! >>>>> >>>>> I've forgot to include the generated examples for this update, so >>>>> I've >>>>> placed it here: >>>>> file:///usr/local/home/lahvac/src/jdk/cr.openjdk.java.net/8192963/webrev.02/diags.html >>>>> >>>>> >>>>> >>>> >>>> I apologize for a wrong link, the correct one is: >>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/diags.html >>>> >>>> Jan >>>> >>>>> >>>>> >>>>> Jan >>>>> >>>>>> >>>>>> Thumbs up. >>>>>> >>>>>> Maurizio >>>>>> >>>>>> >>>>>> On 03/08/18 14:35, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Thanks for all the comments. An updated patch is here: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/ >>>>>>> Changes against the previous revision: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.01.02/ >>>>>>> >>>>>>> Updated specdiff: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/api.diff.02/overview-summary.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Any feedback is welcome. >>>>>>> >>>>>>> Thanks, >>>>>>> ??? Jan >>>>>>> >>>>>>> On 1.8.2018 18:39, Maurizio Cimadamore wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 01/08/18 16:43, Jan Lahoda wrote: >>>>>>>>> Hi Maurizio, >>>>>>>>> >>>>>>>>> Thanks for the comments - responses are inlined. >>>>>>>>> >>>>>>>>> On 1.8.2018 16:04, Maurizio Cimadamore wrote: >>>>>>>>>> Hi Jan, >>>>>>>>>> great work, some comments below. >>>>>>>>>> >>>>>>>>>> * Diagnostics. I see that some diagnostics seem to be >>>>>>>>>> inconsistent >>>>>>>>>> with >>>>>>>>>> what we do for 'return' - e.g. javac diagnostics for 'return' >>>>>>>>>> are >>>>>>>>>> quite >>>>>>>>>> succint: >>>>>>>>>> >>>>>>>>>> - "return outside method" >>>>>>>>>> >>>>>>>>>> - "missing return statement" >>>>>>>>>> >>>>>>>>>> - "unexpected return value" >>>>>>>>>> >>>>>>>>>> - "error: incompatible types: String cannot be converted to int" >>>>>>>>>> >>>>>>>>>> The analogous conditions for break in switch expression seem >>>>>>>>>> to be >>>>>>>>>> more >>>>>>>>>> verbose: >>>>>>>>>> >>>>>>>>>> - "expression break not immediately enclosed by a switch >>>>>>>>>> expression" >>>>>>>>> >>>>>>>>> I think the closest error to "return outside method" is "value >>>>>>>>> break >>>>>>>>> outside of switch expression". The "expression break not >>>>>>>>> immediately >>>>>>>>> enclosed by a switch expression" is used when the break is inside >>>>>>>>> another breakable statement inside the switch expression. I guess >>>>>>>>> this >>>>>>>>> should be rephrased at least to "value break not immediately >>>>>>>>> enclosed >>>>>>>>> by switch expression". >>>>>>>>> >>>>>>>> Fine, but do we need two distinct errors? Or do we need maybe the >>>>>>>> same >>>>>>>> error and an extra detail string at the bottom for the 'you are >>>>>>>> inside a >>>>>>>> switch expr, but there's some other breaky context in between' >>>>>>>> condition? >>>>>>>>>> >>>>>>>>>> - "break is missing a value to return from switch expression" >>>>>>>>> >>>>>>>>> How about >>>>>>>>> "missing break value"? >>>>>>>>> >>>>>>>>> (the break is present, but the value is missing.) >>>>>>>> I'm fine with that! >>>>>>>>> >>>>>>>>>> >>>>>>>>>> - There's no equivalent for the third above - probably the >>>>>>>>>> closest >>>>>>>>>> condition would be to 'break expr' from a switch statement, in >>>>>>>>>> which >>>>>>>>>> case I bet you get a 'missing label' error - should we rectify >>>>>>>>>> that >>>>>>>>>> too? >>>>>>>>> >>>>>>>>> There are several conditions, and the error differ, consider: >>>>>>>>> --- >>>>>>>>> public class SwitchExpr { >>>>>>>>> ????? private void breakTest(int e) { >>>>>>>>> ????????? break ; >>>>>>>>> ????????? break x; >>>>>>>>> ????????? break (e); >>>>>>>>> ????????? while (true) { >>>>>>>>> ?????????????? break x; >>>>>>>>> ?????????????? break (e); >>>>>>>>> ????????? } >>>>>>>>> ????? } >>>>>>>>> } >>>>>>>>> --- >>>>>>>>> >>>>>>>>> This gives: >>>>>>>>> --- >>>>>>>>> SwitchExpr.java:3: error: break outside switch or loop >>>>>>>>> ????????? break ; >>>>>>>>> ????????? ^ >>>>>>>>> SwitchExpr.java:4: error: undefined label: x >>>>>>>>> ????????? break x; >>>>>>>>> ????????? ^ >>>>>>>>> SwitchExpr.java:5: error: value break outside of switch >>>>>>>>> expression >>>>>>>>> ????????? break (e); >>>>>>>>> ????????? ^ >>>>>>>>> SwitchExpr.java:7: error: undefined label: x >>>>>>>>> ?????????????? break x; >>>>>>>>> ?????????????? ^ >>>>>>>>> SwitchExpr.java:8: error: value break outside of switch >>>>>>>>> expression >>>>>>>>> ?????????????? break (e); >>>>>>>>> ?????????????? ^ >>>>>>>>> 5 errors >>>>>>>>> --- >>>>>>>>> >>>>>>>>> So when it is clear the break is a value break, a value break >>>>>>>>> related >>>>>>>>> diagnostic is reported, otherwise, the errors fall back to the >>>>>>>>> existing diagnostics of cannot find labels. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> - "incompatible types: bad type in switch expression" >>>>>>>>>> ... >>>>>>>>>> (A cannot be converted to B) >>>>>>>>> >>>>>>>>> I think this was modelled based on conditional expressions: >>>>>>>>> SwitchExpr.java:10: error: incompatible types: bad type in >>>>>>>>> conditional >>>>>>>>> expression >>>>>>>>> ????????? B b = e == 0 ? (A) null : (B) null; >>>>>>>>> ???????????????????????? ^ >>>>>>>>> ??? A cannot be converted to B >>>>>>>>> >>>>>>>>> I'll look if this can be changed. >>>>>>>> I see, I'm not a big fan of the conditional expression nesting too >>>>>>>> - I >>>>>>>> think the important part is 'A != B' and it should be put front >>>>>>>> and >>>>>>>> center. That said, this is not a blocking issue, and I'm ok with a >>>>>>>> followup. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Not sure whether we should try to maintain the same style across >>>>>>>>>> break/return, but it seemed worth at least pointing out. >>>>>>>>>> >>>>>>>>>> Other diagnostic comments: >>>>>>>>>> >>>>>>>>>> - "error: j is ambiguously both a valid expression and a valid >>>>>>>>>> label" - >>>>>>>>>> this seems convoluted, I would personally rephrase as something >>>>>>>>>> like: >>>>>>>>>> >>>>>>>>>> ambiguous reference to 'j' >>>>>>>>>> ... >>>>>>>>>> ('j' is both a label and an expression) >>>>>>>>> >>>>>>>>> Will done. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> - "break is jumping outside of the enclosing switch >>>>>>>>>> expression" -> >>>>>>>>>> "break outside of enclosing switch expression" >>>>>>>>> >>>>>>>>> Will do. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> - "continue is jumping outside of the enclosing switch >>>>>>>>>> expression" -> >>>>>>>>>> "continue outside of enclosing switch expression" >>>>>>>>> >>>>>>>>> Will do. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> * Attr - The refactoring of switchExpr into switch + >>>>>>>>>> handleSwitch is >>>>>>>>>> very sweet - I like it! >>>>>>>>>> >>>>>>>>>> * Flow - a bit odd that we have to make up a new tree to call >>>>>>>>>> recordExit >>>>>>>>>> - but I see why you're doing it :-) >>>>>>>>>> >>>>>>>>>> * Lower - it would be nice to have a comment on SwitchExpression >>>>>>>>>> that >>>>>>>>>> shows what the generated code shape looks like; I think we do >>>>>>>>>> that >>>>>>>>>> for >>>>>>>>>> other non-trivial translations (e.g. for each) >>>>>>>>> >>>>>>>>> Will do. >>>>>>>> Thanks >>>>>>>> Maurizio >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> ??? Jan >>>>>>>>> >>>>>>>>>> >>>>>>>>>> * ExpSwitchNestingTest - I see that this test is not using the >>>>>>>>>> newer >>>>>>>>>> combo framework. Actually, I'm not even sure this one needs any >>>>>>>>>> templating logic at all, as it seems the test is doing its own >>>>>>>>>> replacements. But I was going to note that this test is not >>>>>>>>>> using the >>>>>>>>>> shared context enhancements, which I guess it's still ok >>>>>>>>>> given the >>>>>>>>>> number of combinations checked is low. Maybe worth keeping an >>>>>>>>>> eye on >>>>>>>>>> this in the future, should we keep adding new cases to it. >>>>>>>>>> >>>>>>>>>> Maurizio >>>>>>>>>> >>>>>>>>>> On 01/08/18 07:28, Jan Lahoda wrote: >>>>>>>>>>> Hi Jon, >>>>>>>>>>> >>>>>>>>>>> Thanks for the comments! >>>>>>>>>>> >>>>>>>>>>> An updated webrev that reflects the comments is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> A delta webrev between this webrev and the webrev.00 is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ >>>>>>>>>>> >>>>>>>>>>> Does this look better? >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> Jan >>>>>>>>>>> >>>>>>>>>>> On 28.7.2018 01:12, Jonathan Gibbons wrote: >>>>>>>>>>>> CaseTree.java:52: spelling, "lables" >>>>>>>>>>>> >>>>>>>>>>>> CaseTree.java:84:? "return" should be "returns". >>>>>>>>>>>> >>>>>>>>>>>> Lots of @Deprecated annotations without corresponding >>>>>>>>>>>> @deprecated >>>>>>>>>>>> javadoc tag. >>>>>>>>>>>> Should the @apiNote really be @deprecated. I also think that >>>>>>>>>>>> using >>>>>>>>>>>> @Deprecated >>>>>>>>>>>> like this is "a bit smelly", and had a discussion with Stuart >>>>>>>>>>>> "Dr >>>>>>>>>>>> Deprecator" regarding >>>>>>>>>>>> my concerns. If nothing else, assuming the feature is a >>>>>>>>>>>> success, we >>>>>>>>>>>> are >>>>>>>>>>>> setting up >>>>>>>>>>>> a precedent of marking an API as deprecated-for-removal, and >>>>>>>>>>>> then >>>>>>>>>>>> in the >>>>>>>>>>>> next >>>>>>>>>>>> release, simply removing the annotation. >>>>>>>>>>>> >>>>>>>>>>>> Attr.java:1482: ugly use of @SuppressWarnings. I understand >>>>>>>>>>>> why >>>>>>>>>>>> it is >>>>>>>>>>>> there, >>>>>>>>>>>> but it exemplifies why @Deprecated on the declaration is a bad >>>>>>>>>>>> idea. >>>>>>>>>>>> It'll be too easy to not remove these annotations in JDK 13. >>>>>>>>>>>> >>>>>>>>>>>> Attr:1825: why XXX >>>>>>>>>>>> >>>>>>>>>>>> LambdaToMethod: unnecessary new import, CaseKind >>>>>>>>>>>> Flow: unnecessary new import, CaseKind >>>>>>>>>>>> >>>>>>>>>>>> JavacParser: order of imports >>>>>>>>>>>> >>>>>>>>>>>> messages: generally, I think the text of the messages could be >>>>>>>>>>>> improved >>>>>>>>>>>> (related but not new) we should somehow identify language >>>>>>>>>>>> keywords >>>>>>>>>>>> from >>>>>>>>>>>> English text (i.e. words like `break, `case`, `continue`, >>>>>>>>>>>> `return`) >>>>>>>>>>>> 204: saying the name is both a valid label and a valid >>>>>>>>>>>> expression >>>>>>>>>>>> hints >>>>>>>>>>>> at the cause but not the error (i.e. the name is ambiguous) >>>>>>>>>>>> >>>>>>>>>>>> JCTree: inconsistent layout of annotations; inconsistent >>>>>>>>>>>> use of >>>>>>>>>>>> @Deprecated and @Deprecated(forRemoval=true) >>>>>>>>>>>> >>>>>>>>>>>> (tests) >>>>>>>>>>>> Not reviewed in detail yet. >>>>>>>>>>>> New test descriptions should use "/*" for jtreg comment block; >>>>>>>>>>>> not >>>>>>>>>>>> "/**". These are not javadoc documentation comments. >>>>>>>>>>>> New test descriptions should have @summary >>>>>>>>>>>> Presumably, we will have to change the -old.out files if the >>>>>>>>>>>> preview >>>>>>>>>>>> feature becomes standard in JDK 13. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Overall, >>>>>>>>>>>> >>>>>>>>>>>> The logic is nice, but the use of @Deprecated(forRemoval=true) >>>>>>>>>>>> and >>>>>>>>>>>> resulting @SuppressWarnings really suck. >>>>>>>>>>>> I don't think the current practice is serving us well. >>>>>>>>>>>> >>>>>>>>>>>> -- Jon >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> As JEP 325 is in the proposed to target state, I thought it >>>>>>>>>>>>> might >>>>>>>>>>>>> be a >>>>>>>>>>>>> good idea to start a review process for the code. >>>>>>>>>>>>> >>>>>>>>>>>>> The code here strives to implement the current specification >>>>>>>>>>>>> for >>>>>>>>>>>>> the >>>>>>>>>>>>> Switch Expressions: >>>>>>>>>>>>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>>>>>>>>>>>> >>>>>>>>>>>>> The current webrev is here: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> (includes a list of new errors.) >>>>>>>>>>>>> >>>>>>>>>>>>> JBS: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>>>>>>>>>>>> >>>>>>>>>>>>> CSRs: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>>>>>>>>>>>> >>>>>>>>>>>>> Any feedback is welcome! >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> ??? Jan >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>> From joe.darcy at oracle.com Thu Aug 9 23:43:47 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 09 Aug 2018 16:43:47 -0700 Subject: about Enum.values() memory allocation In-Reply-To: References: Message-ID: <5B6CD1B3.4040901@oracle.com> Hello, Catching up on email... On 7/25/2018 12:48 PM, Brian Goetz wrote: > This is essentially an API design bug; because values() returns an > array, and arrays are mutable, it must copy the array every time. > Otherwise some miscreant could change the contents of this array, and > other consumers of `values()` would see wrong data. > > There are a number of ways this could be improved, each with their > pros and cons: > > - Add a new method, valuesAsList(), which would return an immutable > list which could be cached and shared. (Arguably this is what > Enum::values should have done in the first place.) Easy to add, but > puts the burden on users to change their code. At the time in JDK 5.0, there was a concern about using java.util APIs in java.lang.* classes. Now that both java.lang and java.util packages are ensconced in the java.base module, such concerns are no longer germane. Cheers, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Aug 15 15:04:00 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 15 Aug 2018 11:04:00 -0400 Subject: RFR: JDK-8207320: Wrong type order for intersection lambdas with multiple abstract methods In-Reply-To: <95fb6d8d-e1bd-c769-1570-c54bb496d8b7@oracle.com> References: <95fb6d8d-e1bd-c769-1570-c54bb496d8b7@oracle.com> Message-ID: <3228c3c1-efa1-6e9f-7719-8f767582098c@oracle.com> Please review the fix for [1] at [2]. The fix is modifying the way intersection types are erased. Javac erases an intersection type to its first component, but it is not always the right choice. This patch fixes that issue. As an additional information please check Dan's comments in the bug entry, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8207320 [2] http://cr.openjdk.java.net/~vromero/8207320/webrev.00/jdk.dev.patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed Aug 15 15:20:25 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 15 Aug 2018 17:20:25 +0200 (CEST) Subject: RFR: JDK-8207320: Wrong type order for intersection lambdas with multiple abstract methods In-Reply-To: <3228c3c1-efa1-6e9f-7719-8f767582098c@oracle.com> References: <95fb6d8d-e1bd-c769-1570-c54bb496d8b7@oracle.com> <3228c3c1-efa1-6e9f-7719-8f767582098c@oracle.com> Message-ID: <789165165.141945.1534346425382.JavaMail.zimbra@u-pem.fr> Hi Vicente, i do not think that changing the way an intersection type is erased is the good way to solve that issue, it's a risky move as a lot of codes rely on javac erasing an intersection type to its first component. I think it's better to report an error when the lambda target type doesn't include the method of the method reference with a message indicating how the intersection type should be written. regards, R?mi > De: "Vicente Romero" > ?: "compiler-dev" > Envoy?: Mercredi 15 Ao?t 2018 17:04:00 > Objet: RFR: JDK-8207320: Wrong type order for intersection lambdas with multiple > abstract methods > Please review the fix for [1] at [2]. The fix is modifying the way intersection > types are erased. Javac erases an intersection type to its first component, but > it is not always the right choice. This patch fixes that issue. As an > additional information please check Dan's comments in the bug entry, > Thanks, > Vicente > [1] [ https://bugs.openjdk.java.net/browse/JDK-8207320 | > https://bugs.openjdk.java.net/browse/JDK-8207320 ] > [2] [ http://cr.openjdk.java.net/%7Evromero/8207320/webrev.00/jdk.dev.patch | > http://cr.openjdk.java.net/~vromero/8207320/webrev.00/jdk.dev.patch ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Aug 15 15:44:19 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 15 Aug 2018 16:44:19 +0100 Subject: RFR: JDK-8207320: Wrong type order for intersection lambdas with multiple abstract methods In-Reply-To: <3228c3c1-efa1-6e9f-7719-8f767582098c@oracle.com> References: <95fb6d8d-e1bd-c769-1570-c54bb496d8b7@oracle.com> <3228c3c1-efa1-6e9f-7719-8f767582098c@oracle.com> Message-ID: <76662f3f-6e8f-0dba-1fb4-1dcea9d3d1e2@oracle.com> Hi, I agree that there's a bug somewhere in javac's code generation - but I believe this fix is too wide, as it touches how erasure of all cast expression is performed. I think this issue has only to do with the synthetic receiver parameter of a method reference, which seems to be captured incorrectly. That is, the lambda translation machinery knows well that the receiver ought to be AB (in fact that's what ends up in the metafactory protocol), but when the receiver argument is captured, no cast is emitted. I think this could be just matter of generating the right checkcast at the right time. More specifically, in LambdaToMethod, I see this (method visitReference): ??????????? case BOUND:???????????? /** Expr :: instMethod */ ??????????????? init = tree.getQualifierExpression(); Now, since this will simply get the (erased) qualifier expression and pass it to the indy as its dynamic argument, we have to handle cases where there's a disconnect between the erased type of the qualifier expression and the expected receiver type (tree.sym.owner.type). I think you need a call to transTypes.coerce (as done in other places) at that point, to ensure the receiver arg conforms with what the MH expects. Maurizio On 15/08/18 16:04, Vicente Romero wrote: > Please review the fix for [1] at [2]. The fix is modifying the way > intersection types are erased. Javac erases an intersection type to > its first component, but it is not always the right choice. This patch > fixes that issue. As an additional information please check Dan's > comments in the bug entry, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8207320 > [2] http://cr.openjdk.java.net/~vromero/8207320/webrev.00/jdk.dev.patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Aug 15 19:35:30 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 15 Aug 2018 15:35:30 -0400 Subject: RFR: JDK-8207320: Wrong type order for intersection lambdas with multiple abstract methods In-Reply-To: <76662f3f-6e8f-0dba-1fb4-1dcea9d3d1e2@oracle.com> References: <95fb6d8d-e1bd-c769-1570-c54bb496d8b7@oracle.com> <3228c3c1-efa1-6e9f-7719-8f767582098c@oracle.com> <76662f3f-6e8f-0dba-1fb4-1dcea9d3d1e2@oracle.com> Message-ID: Hi Maurizio, Thanks for your comments. I have uploaded another iteration [3]. I also added another regression test. All Tier1 tests passed. Vicente [3] http://cr.openjdk.java.net/~vromero/8207320/webrev.01/jdk.dev.patch On 08/15/2018 11:44 AM, Maurizio Cimadamore wrote: > > Hi, > I agree that there's a bug somewhere in javac's code generation - but > I believe this fix is too wide, as it touches how erasure of all cast > expression is performed. I think this issue has only to do with the > synthetic receiver parameter of a method reference, which seems to be > captured incorrectly. That is, the lambda translation machinery knows > well that the receiver ought to be AB (in fact that's what ends up in > the metafactory protocol), but when the receiver argument is captured, > no cast is emitted. > > I think this could be just matter of generating the right checkcast at > the right time. > > More specifically, in LambdaToMethod, I see this (method visitReference): > > ??????????? case BOUND:???????????? /** Expr :: instMethod */ > ??????????????? init = tree.getQualifierExpression(); > > Now, since this will simply get the (erased) qualifier expression and > pass it to the indy as its dynamic argument, we have to handle cases > where there's a disconnect between the erased type of the qualifier > expression and the expected receiver type (tree.sym.owner.type). I > think you need a call to transTypes.coerce (as done in other places) > at that point, to ensure the receiver arg conforms with what the MH > expects. > > Maurizio > > > On 15/08/18 16:04, Vicente Romero wrote: >> Please review the fix for [1] at [2]. The fix is modifying the way >> intersection types are erased. Javac erases an intersection type to >> its first component, but it is not always the right choice. This >> patch fixes that issue. As an additional information please check >> Dan's comments in the bug entry, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8207320 >> [2] http://cr.openjdk.java.net/~vromero/8207320/webrev.00/jdk.dev.patch > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed Aug 15 20:33:12 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 15 Aug 2018 21:33:12 +0100 Subject: RFR: JDK-8207320: Wrong type order for intersection lambdas with multiple abstract methods In-Reply-To: References: <95fb6d8d-e1bd-c769-1570-c54bb496d8b7@oracle.com> <3228c3c1-efa1-6e9f-7719-8f767582098c@oracle.com> <76662f3f-6e8f-0dba-1fb4-1dcea9d3d1e2@oracle.com> Message-ID: <7981f7bb-a3f2-c68f-7ea7-b1d22c1e055d@oracle.com> This looks good! I wonder if we can get to a similar issue with intersection types inferred for a captured var from a lambda. This is possible e.g. if the variable being captured is declared with 'var', I think. Then, I believe we will end up in a very similar case - where the signature of the indy says one thing, and the static type of the dynamic argument being passed to it has an incompatible type. But maybe that can't happen - as the type of the captured arguments is inferred from the argument expressions themselves. So perhaps there can't be a mismatch (here the problem was that the method handle had a receiver of type R1 and the receiver expression turned out with a different receiver type R2). I'll keep thinking about this case for a while, to see if something pops up, but in the meantime this fix looks good to go. P.S. If I recall correctly, the coerce method does not generate a cast unless necessary, right? Maurizio On 15/08/18 20:35, Vicente Romero wrote: > Hi Maurizio, > > Thanks for your comments. I have uploaded another iteration [3]. I > also added another regression test. All Tier1 tests passed. > > Vicente > > [3] http://cr.openjdk.java.net/~vromero/8207320/webrev.01/jdk.dev.patch > > On 08/15/2018 11:44 AM, Maurizio Cimadamore wrote: >> >> Hi, >> I agree that there's a bug somewhere in javac's code generation - but >> I believe this fix is too wide, as it touches how erasure of all cast >> expression is performed. I think this issue has only to do with the >> synthetic receiver parameter of a method reference, which seems to be >> captured incorrectly. That is, the lambda translation machinery knows >> well that the receiver ought to be AB (in fact that's what ends up in >> the metafactory protocol), but when the receiver argument is >> captured, no cast is emitted. >> >> I think this could be just matter of generating the right checkcast >> at the right time. >> >> More specifically, in LambdaToMethod, I see this (method visitReference): >> >> ??????????? case BOUND:???????????? /** Expr :: instMethod */ >> ??????????????? init = tree.getQualifierExpression(); >> >> Now, since this will simply get the (erased) qualifier expression and >> pass it to the indy as its dynamic argument, we have to handle cases >> where there's a disconnect between the erased type of the qualifier >> expression and the expected receiver type (tree.sym.owner.type). I >> think you need a call to transTypes.coerce (as done in other places) >> at that point, to ensure the receiver arg conforms with what the MH >> expects. >> >> Maurizio >> >> >> On 15/08/18 16:04, Vicente Romero wrote: >>> Please review the fix for [1] at [2]. The fix is modifying the way >>> intersection types are erased. Javac erases an intersection type to >>> its first component, but it is not always the right choice. This >>> patch fixes that issue. As an additional information please check >>> Dan's comments in the bug entry, >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8207320 >>> [2] http://cr.openjdk.java.net/~vromero/8207320/webrev.00/jdk.dev.patch >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Wed Aug 15 20:50:36 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 15 Aug 2018 16:50:36 -0400 Subject: RFR: JDK-8207320: Wrong type order for intersection lambdas with multiple abstract methods In-Reply-To: <7981f7bb-a3f2-c68f-7ea7-b1d22c1e055d@oracle.com> References: <95fb6d8d-e1bd-c769-1570-c54bb496d8b7@oracle.com> <3228c3c1-efa1-6e9f-7719-8f767582098c@oracle.com> <76662f3f-6e8f-0dba-1fb4-1dcea9d3d1e2@oracle.com> <7981f7bb-a3f2-c68f-7ea7-b1d22c1e055d@oracle.com> Message-ID: <64e1af89-b37f-30ae-7daa-7cdae03a91c0@oracle.com> On 08/15/2018 04:33 PM, Maurizio Cimadamore wrote: > > This looks good! > > I wonder if we can get to a similar issue with intersection types > inferred for a captured var from a lambda. This is possible e.g. if > the variable being captured is declared with 'var', I think. Then, I > believe we will end up in a very similar case - where the signature of > the indy says one thing, and the static type of the dynamic argument > being passed to it has an incompatible type. > > But maybe that can't happen - as the type of the captured arguments is > inferred from the argument expressions themselves. So perhaps there > can't be a mismatch (here the problem was that the method handle had a > receiver of type R1 and the receiver expression turned out with a > different receiver type R2). > > I'll keep thinking about this case for a while, to see if something > pops up, but in the meantime this fix looks good to go. :) > > P.S. > If I recall correctly, the coerce method does not generate a cast > unless necessary, right? right only if necessary > > Maurizio going for it, thanks for your comments, Vicente > > On 15/08/18 20:35, Vicente Romero wrote: >> Hi Maurizio, >> >> Thanks for your comments. I have uploaded another iteration [3]. I >> also added another regression test. All Tier1 tests passed. >> >> Vicente >> >> [3] http://cr.openjdk.java.net/~vromero/8207320/webrev.01/jdk.dev.patch >> >> On 08/15/2018 11:44 AM, Maurizio Cimadamore wrote: >>> >>> Hi, >>> I agree that there's a bug somewhere in javac's code generation - >>> but I believe this fix is too wide, as it touches how erasure of all >>> cast expression is performed. I think this issue has only to do with >>> the synthetic receiver parameter of a method reference, which seems >>> to be captured incorrectly. That is, the lambda translation >>> machinery knows well that the receiver ought to be AB (in fact >>> that's what ends up in the metafactory protocol), but when the >>> receiver argument is captured, no cast is emitted. >>> >>> I think this could be just matter of generating the right checkcast >>> at the right time. >>> >>> More specifically, in LambdaToMethod, I see this (method >>> visitReference): >>> >>> ??????????? case BOUND:???????????? /** Expr :: instMethod */ >>> ??????????????? init = tree.getQualifierExpression(); >>> >>> Now, since this will simply get the (erased) qualifier expression >>> and pass it to the indy as its dynamic argument, we have to handle >>> cases where there's a disconnect between the erased type of the >>> qualifier expression and the expected receiver type >>> (tree.sym.owner.type). I think you need a call to transTypes.coerce >>> (as done in other places) at that point, to ensure the receiver arg >>> conforms with what the MH expects. >>> >>> Maurizio >>> >>> >>> On 15/08/18 16:04, Vicente Romero wrote: >>>> Please review the fix for [1] at [2]. The fix is modifying the way >>>> intersection types are erased. Javac erases an intersection type to >>>> its first component, but it is not always the right choice. This >>>> patch fixes that issue. As an additional information please check >>>> Dan's comments in the bug entry, >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8207320 >>>> [2] http://cr.openjdk.java.net/~vromero/8207320/webrev.00/jdk.dev.patch >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Fri Aug 17 13:25:20 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 17 Aug 2018 15:25:20 +0200 Subject: RFR: JDK-8181854: NullPointerException in com.sun.tools.javac.api.JavacTrees.getElement Message-ID: <5B76CCC0.1060103@oracle.com> Hi, The problem described in this bug is that when the source code contains javadoc reference like: {@link List ...} (which is not valid), calling DocTrees.getElement(DocTreePath) for the reference leads to a NPE. The reason is that internally, the method will call Attr.attribIdent for an AST that corresponds to "List", but attribIdent can only handle identifiers and member selects. The proposed solution is to avoid calling attribIdent if the AST node is not an identifier or member select. Webrev: http://cr.openjdk.java.net/~jlahoda/8181854/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8181854 Any feedback is welcome. Thanks, Jan From vicente.romero at oracle.com Fri Aug 17 13:50:30 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 17 Aug 2018 09:50:30 -0400 Subject: RFR: JDK-8181854: NullPointerException in com.sun.tools.javac.api.JavacTrees.getElement In-Reply-To: <5B76CCC0.1060103@oracle.com> References: <5B76CCC0.1060103@oracle.com> Message-ID: <2e8a0091-839e-960f-2622-e92f6f8bba7b@oracle.com> looks good, Vicente On 08/17/2018 09:25 AM, Jan Lahoda wrote: > Hi, > > The problem described in this bug is that when the source code > contains javadoc reference like: > {@link List ...} > (which is not valid), calling DocTrees.getElement(DocTreePath) for the > reference leads to a NPE. The reason is that internally, the method > will call Attr.attribIdent for an AST that corresponds to "List", > but attribIdent can only handle identifiers and member selects. The > proposed solution is to avoid calling attribIdent if the AST node is > not an identifier or member select. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8181854/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8181854 > > Any feedback is welcome. > > Thanks, > ?? Jan From jonathan.gibbons at oracle.com Fri Aug 17 15:15:59 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 17 Aug 2018 08:15:59 -0700 Subject: RFR: JDK-8181854: NullPointerException in com.sun.tools.javac.api.JavacTrees.getElement In-Reply-To: <5B76CCC0.1060103@oracle.com> References: <5B76CCC0.1060103@oracle.com> Message-ID: <05902962-191b-bdfb-1fff-6408fd492b08@oracle.com> Jan, Ideally, javadoc (i.e. the doctree API) should handle generic types.? As a partial solution, is it worth detecting, and ignoring '<...>' so that we treat 'List' as 'List'. -- Jon On 8/17/18 6:25 AM, Jan Lahoda wrote: > Hi, > > The problem described in this bug is that when the source code > contains javadoc reference like: > {@link List ...} > (which is not valid), calling DocTrees.getElement(DocTreePath) for the > reference leads to a NPE. The reason is that internally, the method > will call Attr.attribIdent for an AST that corresponds to "List", > but attribIdent can only handle identifiers and member selects. The > proposed solution is to avoid calling attribIdent if the AST node is > not an identifier or member select. > > Webrev: http://cr.openjdk.java.net/~jlahoda/8181854/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8181854 > > Any feedback is welcome. > > Thanks, > ?? Jan From jan.lahoda at oracle.com Fri Aug 17 16:27:20 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 17 Aug 2018 18:27:20 +0200 Subject: RFR: JDK-8181854: NullPointerException in com.sun.tools.javac.api.JavacTrees.getElement In-Reply-To: <05902962-191b-bdfb-1fff-6408fd492b08@oracle.com> References: <5B76CCC0.1060103@oracle.com> <05902962-191b-bdfb-1fff-6408fd492b08@oracle.com> Message-ID: <5B76F768.7030102@oracle.com> On 17.8.2018 17:15, Jonathan Gibbons wrote: > Jan, > > Ideally, javadoc (i.e. the doctree API) should handle generic types. As > a partial solution, is it worth detecting, and ignoring '<...>' so that > we treat 'List' as 'List'. For the DocTrees.getElement method, I don't think we can do much to handle the '<' - the method returns only Element/Symbol. Please note that in the patch, it will return (Element for) j.u.List for "List", as the preceding "attr.attribType(ref.qualifierExpression, env)" will be able to attribute the type, and I've changed the subsequent check from Type.isErroneous() (which also checks validity of the "nested" types, like type parameters) to Type.hasTag(ERROR) which should only filter cases where the type itself is not resolvable. For support for generic types, we could either add a simple: TypeMirror DocTrees.getTypeMirror(DocTreePath) Or even something more elaborate, that could allow to parse and attribute types from a string representation. Thanks, Jan > > -- Jon > > > On 8/17/18 6:25 AM, Jan Lahoda wrote: >> Hi, >> >> The problem described in this bug is that when the source code >> contains javadoc reference like: >> {@link List ...} >> (which is not valid), calling DocTrees.getElement(DocTreePath) for the >> reference leads to a NPE. The reason is that internally, the method >> will call Attr.attribIdent for an AST that corresponds to "List", >> but attribIdent can only handle identifiers and member selects. The >> proposed solution is to avoid calling attribIdent if the AST node is >> not an identifier or member select. >> >> Webrev: http://cr.openjdk.java.net/~jlahoda/8181854/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8181854 >> >> Any feedback is welcome. >> >> Thanks, >> Jan > From magnus.ihse.bursie at oracle.com Tue Aug 21 09:31:56 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 21 Aug 2018 11:31:56 +0200 Subject: RFR 8209064: Make intellij support more robust after changes for 2018.2 In-Reply-To: <63022bb6-5a5e-8b34-b73f-a7f7a368f8f4@oracle.com> References: <63022bb6-5a5e-8b34-b73f-a7f7a368f8f4@oracle.com> Message-ID: <698c5ed2-604a-2425-a867-5bfbfa897c3b@oracle.com> Hi Maurizio! Even if this only incidentally relates to the build, please always include build-dev when making changes in the "make" directory. As far as I can understand, your changes looks good. One question: the build.xml was previously stored as a "template", and copied to the output directory. Now it's left in the source tree. I assume that there was no actual transformations or changes made to the template before? So that the scripts do not modify the source tree version, that is. /Magnus On 2018-08-07 13:21, Maurizio Cimadamore wrote: > Hi, > last week I submitted an 'emergency' patch to fix intellij project > support after 2018.2 changes. The goal of these changes was to move > the build.xml ant file out of the .idea folder, as the IDE no longer > supported DOM indexing in such folders (as a result of > https://youtrack.jetbrains.com/issue/IDEA-189915). As a workaround, I > tweaked the scripts to copy build.xml in the build folder. > > Thinking more about this issue, there's a more robust fix possible, > which doesn't involve moving files to the build folder (which could be > potentially unreliable, depending on how people build the JDK). In > fact, the best solution is to leave build.xml where it is, and fix the > remaining configuration files to point at it. This allows to revert > all changes in the scripts that set up the project configuration > (bin/idea.sh for JDK, and make/langtools/build.xml for langtools). > > For the langtools project a bit more changes were necessary, given > that in langtools we did not have a 'template' folder - and all > intellij files were dumped onto the same path. So I had to move the > configuration langtools files (all but build.xml) under a new template > folder (located under make/langtools/intellij/make) and place > build.xml outside it. Then tweak the build.xml script to work off this > new template folder. These are all small conceptual changes, but the > impact on the webrev is quite biggie (because of file renaming etc.). > > I also took the chance to fix some issues with the JDK project ANT > configuration (see changes in make/idea/template/workspace.xml), as > the last changes did not update the location of the ant file used here > - as a result no ant target entries were showing up under the Build menu. > > Webrev here: > > http://cr.openjdk.java.net/~mcimadamore/8209064/ > > Cheers > Maurizio > From seth.lytle at gmail.com Wed Aug 22 06:07:28 2018 From: seth.lytle at gmail.com (seth lytle) Date: Wed, 22 Aug 2018 02:07:28 -0400 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream Message-ID: i'm working on adding JEP 330 single-file source invocation support to kilim (an ASM-based continuations library for java for which i'm the primary maintainer). we're prepping to promote my fork to the main site and i'd like to be able to support java 11 single-file source invocation as easily as classpath-based invocation, or at least confirm that the differences are intentional - i need access to the bytecode to weave it at runtime - MemoryClassLoader doesn't provide getResourceAsStream - it does cache the bytecode, so providing this appears to be easy to implement - currently, i access it with a javaagent that mimics MemoryClassLoader.map - https://github.com/nqzero/kilim/#java-versions - getResource is also missing, and again, much of the plumbing appears to be in place - i haven't tried manually building the "memory:///" style urls an example of my current invocation: cp=$(mvn -q dependency:build-classpath -Dmdep.outputFile=/dev/fd/1) $java11/bin/java -javaagent:${cp/:*} -cp $cp Xorshift.java what i'd like to be able to do: $java11/bin/java -cp $cp Xorshift.java i saw a previous thread that mentioned getResource in passing but no discussion of whether it was considered (un)desirable. is this feature planned ? are there problems with introducing it ? thanks for the great addition to java - using JEP 330 feels fun -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Wed Aug 22 19:41:04 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 22 Aug 2018 12:41:04 -0700 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream In-Reply-To: References: Message-ID: <5B7DBC50.4050100@oracle.com> Hi Seth, The provision of getResourceAsStream and getResource was considered in the implementation of the Source File Launcher feature ... and was dismissed at that time. * There are no "normal" resources in the (internal) MemoryClassLoader; there are only the class files generated from the source file. This implies that the provision of these methods in MCL is just for the benefit for folk wanting access to the bytyes for a .class file. (I'm not that that's bad; I'm just saying that is so.) * Yes, we could reasonably easily provide getResourceAsStream, but it seems weird to provide getResourceAsStream without also providing an equivalent getResource, but URLs are not (currently) supported for the content of the MemoryClassLoader. Yes, internally, some "fake" URLs are created to keep the API happy, but these are not intended to be used by the end-user, and you'll get an error if you try and open a stream from the URL. I would defer to ClassLoader experts as to whether it is reasonable to provide getResourceAsStream but not getResource. It might be reasonable the jdk.compiler module to provide a URLStreamHandlerProvider for these URLs; that would require some consideration. -- Jon On 08/21/2018 11:07 PM, seth lytle wrote: > i'm working on adding JEP 330 single-file source invocation support to > kilim (an ASM-based continuations library for java for which i'm the > primary maintainer). we're prepping to promote my fork to the main > site and i'd like to be able to support java 11 single-file source > invocation as easily as classpath-based invocation, or at least > confirm that the differences are intentional > > - i need access to the bytecode to weave it at runtime > - MemoryClassLoader doesn't provide getResourceAsStream > - it does cache the bytecode, so providing this appears to be easy to > implement > - currently, i access it with a javaagent that mimics > MemoryClassLoader.map > - https://github.com/nqzero/kilim/#java-versions > - getResource is also missing, and again, much of the plumbing appears > to be in place > - i haven't tried manually building the "memory:///" style urls > > an example of my current invocation: > cp=$(mvn -q dependency:build-classpath -Dmdep.outputFile=/dev/fd/1) > $java11/bin/java -javaagent:${cp/:*} -cp $cp Xorshift.java > > what i'd like to be able to do: > $java11/bin/java -cp $cp Xorshift.java > > > i saw a previous thread that mentioned getResource in passing but no > discussion of whether it was considered (un)desirable. is this feature > planned ? are there problems with introducing it ? > > > thanks for the great addition to java - using JEP 330 feels fun > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Aug 23 13:21:07 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 23 Aug 2018 14:21:07 +0100 Subject: RFR 8209064: Make intellij support more robust after changes for 2018.2 In-Reply-To: <698c5ed2-604a-2425-a867-5bfbfa897c3b@oracle.com> References: <63022bb6-5a5e-8b34-b73f-a7f7a368f8f4@oracle.com> <698c5ed2-604a-2425-a867-5bfbfa897c3b@oracle.com> Message-ID: On 21/08/18 10:31, Magnus Ihse Bursie wrote: > Hi Maurizio! > > Even if this only incidentally relates to the build, please always > include build-dev when making changes in the "make" directory. I will - thanks > > As far as I can understand, your changes looks good. One question: the > build.xml was previously stored as a "template", and copied to the > output directory. Now it's left in the source tree. I assume that > there was no actual transformations or changes made to the template > before? So that the scripts do not modify the source tree version, > that is. You are correct - the script is not meant to be modified; customized properties are injected by the runtime environment - such properties are defined in the ant.xml file and that is indeed a template file (so it can be customized). Thanks Maurizio > > /Magnus > > On 2018-08-07 13:21, Maurizio Cimadamore wrote: >> Hi, >> last week I submitted an 'emergency' patch to fix intellij project >> support after 2018.2 changes. The goal of these changes was to move >> the build.xml ant file out of the .idea folder, as the IDE no longer >> supported DOM indexing in such folders (as a result of >> https://youtrack.jetbrains.com/issue/IDEA-189915). As a workaround, I >> tweaked the scripts to copy build.xml in the build folder. >> >> Thinking more about this issue, there's a more robust fix possible, >> which doesn't involve moving files to the build folder (which could >> be potentially unreliable, depending on how people build the JDK). In >> fact, the best solution is to leave build.xml where it is, and fix >> the remaining configuration files to point at it. This allows to >> revert all changes in the scripts that set up the project >> configuration (bin/idea.sh for JDK, and make/langtools/build.xml for >> langtools). >> >> For the langtools project a bit more changes were necessary, given >> that in langtools we did not have a 'template' folder - and all >> intellij files were dumped onto the same path. So I had to move the >> configuration langtools files (all but build.xml) under a new >> template folder (located under make/langtools/intellij/make) and >> place build.xml outside it. Then tweak the build.xml script to work >> off this new template folder. These are all small conceptual changes, >> but the impact on the webrev is quite biggie (because of file >> renaming etc.). >> >> I also took the chance to fix some issues with the JDK project ANT >> configuration (see changes in make/idea/template/workspace.xml), as >> the last changes did not update the location of the ant file used >> here - as a result no ant target entries were showing up under the >> Build menu. >> >> Webrev here: >> >> http://cr.openjdk.java.net/~mcimadamore/8209064/ >> >> Cheers >> Maurizio >> > From seth.lytle at gmail.com Thu Aug 23 22:13:28 2018 From: seth.lytle at gmail.com (seth lytle) Date: Thu, 23 Aug 2018 18:13:28 -0400 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream In-Reply-To: <5B7DBC50.4050100@oracle.com> References: <5B7DBC50.4050100@oracle.com> Message-ID: thanks Jon (and sorry for the duplicate msg) > I would defer to ClassLoader experts as to whether it is reasonable to provide getResourceAsStream but not getResource is the core-libs-dev list the best place to ask if this is reasonable ? > provide a URLStreamHandlerProvider yes, that seems like a bigger job On Wed, Aug 22, 2018 at 3:41 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Hi Seth, > > The provision of getResourceAsStream and getResource was considered in the > implementation of the Source File Launcher feature ... and was dismissed at > that time. > > * There are no "normal" resources in the (internal) MemoryClassLoader; > there are only the class files generated from the source file. This implies > that the provision of these methods in MCL is just for the benefit for folk > wanting access to the bytyes for a .class file. (I'm not that that's bad; > I'm just saying that is so.) > > * Yes, we could reasonably easily provide getResourceAsStream, but it > seems weird to provide getResourceAsStream without also providing an > equivalent getResource, but URLs are not (currently) supported for the > content of the MemoryClassLoader. Yes, internally, some "fake" URLs are > created to keep the API happy, but these are not intended to be used by the > end-user, and you'll get an error if you try and open a stream from the > URL. I would defer to ClassLoader experts as to whether it is reasonable > to provide getResourceAsStream but not getResource. > > It might be reasonable the jdk.compiler module to provide a > URLStreamHandlerProvider for these URLs; that would require some > consideration. > > -- Jon > > > > > On 08/21/2018 11:07 PM, seth lytle wrote: > > i'm working on adding JEP 330 single-file source invocation support to > kilim (an ASM-based continuations library for java for which i'm the > primary maintainer). we're prepping to promote my fork to the main site > and i'd like to be able to support java 11 single-file source invocation as > easily as classpath-based invocation, or at least confirm that the > differences are intentional > > - i need access to the bytecode to weave it at runtime > - MemoryClassLoader doesn't provide getResourceAsStream > - it does cache the bytecode, so providing this appears to be easy to > implement > - currently, i access it with a javaagent that mimics MemoryClassLoader.map > - https://github.com/nqzero/kilim/#java-versions > - getResource is also missing, and again, much of the plumbing appears to > be in place > - i haven't tried manually building the "memory:///" style urls > > an example of my current invocation: > cp=$(mvn -q dependency:build-classpath -Dmdep.outputFile=/dev/fd/1) > $java11/bin/java -javaagent:${cp/:*} -cp $cp Xorshift.java > > what i'd like to be able to do: > $java11/bin/java -cp $cp Xorshift.java > > > i saw a previous thread that mentioned getResource in passing but no > discussion of whether it was considered (un)desirable. is this feature > planned ? are there problems with introducing it ? > > > thanks for the great addition to java - using JEP 330 feels fun > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Aug 23 22:16:14 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 23 Aug 2018 15:16:14 -0700 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream In-Reply-To: References: <5B7DBC50.4050100@oracle.com> Message-ID: <5B7F322E.20602@oracle.com> On 08/23/2018 03:11 PM, seth lytle wrote: > thanks Jon > > > I would defer to ClassLoader experts as to whether it is reasonable > to provide getResourceAsStream but not getResource > > is the core-libs-dev list the best place to ask if this is reasonable ? Yes, that would be the place to ask. -- Jon > > >provide a URLStreamHandlerProvider > > yes, that seems like a bigger job > > > > > > > On Wed, Aug 22, 2018 at 3:41 PM, Jonathan Gibbons > > wrote: > > Hi Seth, > > The provision of getResourceAsStream and getResource was > considered in the implementation of the Source File Launcher > feature ... and was dismissed at that time. > > * There are no "normal" resources in the (internal) > MemoryClassLoader; there are only the class files generated from > the source file. This implies that the provision of these methods > in MCL is just for the benefit for folk wanting access to the > bytyes for a .class file. (I'm not that that's bad; I'm just > saying that is so.) > > * Yes, we could reasonably easily provide getResourceAsStream, but > it seems weird to provide getResourceAsStream without also > providing an equivalent getResource, but URLs are not (currently) > supported for the content of the MemoryClassLoader. Yes, > internally, some "fake" URLs are created to keep the API happy, > but these are not intended to be used by the end-user, and you'll > get an error if you try and open a stream from the URL. I would > defer to ClassLoader experts as to whether it is reasonable to > provide getResourceAsStream but not getResource. > > It might be reasonable the jdk.compiler module to provide a > URLStreamHandlerProvider for these URLs; that would require some > consideration. > > -- Jon > > > > > On 08/21/2018 11:07 PM, seth lytle wrote: >> i'm working on adding JEP 330 single-file source invocation >> support to kilim (an ASM-based continuations library for java for >> which i'm the primary maintainer). we're prepping to promote my >> fork to the main site and i'd like to be able to support java 11 >> single-file source invocation as easily as classpath-based >> invocation, or at least confirm that the differences are intentional >> >> - i need access to the bytecode to weave it at runtime >> - MemoryClassLoader doesn't provide getResourceAsStream >> - it does cache the bytecode, so providing this appears to be >> easy to implement >> - currently, i access it with a javaagent that mimics >> MemoryClassLoader.map >> - https://github.com/nqzero/kilim/#java-versions >> >> - getResource is also missing, and again, much of the plumbing >> appears to be in place >> - i haven't tried manually building the "memory:///" style urls >> >> an example of my current invocation: >> cp=$(mvn -q dependency:build-classpath -Dmdep.outputFile=/dev/fd/1) >> $java11/bin/java -javaagent:${cp/:*} -cp $cp Xorshift.java >> >> what i'd like to be able to do: >> $java11/bin/java -cp $cp Xorshift.java >> >> >> i saw a previous thread that mentioned getResource in passing but >> no discussion of whether it was considered (un)desirable. is this >> feature planned ? are there problems with introducing it ? >> >> >> thanks for the great addition to java - using JEP 330 feels fun >> >> >> >> >> >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Aug 24 19:52:27 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 24 Aug 2018 15:52:27 -0400 Subject: RFR JDK-8209173: javac fails with completion exception while reporting an error Message-ID: <6d8378f8-a9ed-f99e-7632-2a34b55f8a9a@oracle.com> Hi, Please review patch for [1] at [2]. The original issue was reported for a combination of a Scala class and a client class written in Java. When the Java class was compiled with javac, it couldn't find in the class path a class imported by the Scala class, the missing class belongs to the Scala standard library. The root issue was that the symbol corresponding to the missing Scala class could not be completed and a completion exception was thrown. The exception was fired while javac was producing the corresponding diagnostic error message. Later on the compiler was swallowing the exception, but the AST ended up having null fields. This provoked a NPE during a later compilation phase. The provided test reproduces the issue using Java classes only. Thanks [1] https://bugs.openjdk.java.net/browse/JDK-8209173 [2] http://cr.openjdk.java.net/~vromero/8209173/webrev.00/ From maurizio.cimadamore at oracle.com Fri Aug 24 20:31:21 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 24 Aug 2018 21:31:21 +0100 Subject: RFR JDK-8209173: javac fails with completion exception while reporting an error In-Reply-To: <6d8378f8-a9ed-f99e-7632-2a34b55f8a9a@oracle.com> References: <6d8378f8-a9ed-f99e-7632-2a34b55f8a9a@oracle.com> Message-ID: Hi, the fix looks good. If I understand correctly, the issue was that, since the diagnostic generation ended up with an exception, the diagnostic never really arrived at the speculative attribution handler, which meant it was not reported. Correct? Maurizio On 24/08/18 20:52, Vicente Romero wrote: > Hi, > > Please review patch for [1] at [2]. The original issue was reported > for a combination of a Scala class and a client class written in Java. > When the Java class was compiled with javac, it couldn't find in the > class path a class imported by the Scala class, the missing class > belongs to the Scala standard library. The root issue was that the > symbol corresponding to the missing Scala class could not be completed > and a completion exception was thrown. The exception was fired while > javac was producing the corresponding diagnostic error message. Later > on the compiler was swallowing the exception, but the AST ended up > having null fields. This provoked a NPE during a later compilation > phase. The provided test reproduces the issue using Java classes only. > > Thanks > > [1] https://bugs.openjdk.java.net/browse/JDK-8209173 > [2] http://cr.openjdk.java.net/~vromero/8209173/webrev.00/ From vicente.romero at oracle.com Fri Aug 24 20:42:41 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 24 Aug 2018 16:42:41 -0400 Subject: RFR JDK-8209173: javac fails with completion exception while reporting an error In-Reply-To: References: <6d8378f8-a9ed-f99e-7632-2a34b55f8a9a@oracle.com> Message-ID: <0c0cda58-b305-2ff8-46b8-cf9797f31dea@oracle.com> On 08/24/2018 04:31 PM, Maurizio Cimadamore wrote: > Hi, > the fix looks good. If I understand correctly, the issue was that, > since the diagnostic generation ended up with an exception, the > diagnostic never really arrived at the speculative attribution > handler, which meant it was not reported. Correct? correct, although at the end it was not the speculative attribution handler the one that was involved here. I mistakingly thought that, it was just the default handler, but your still your analysis is correct > > Maurizio thanks for the review Vicente > > > On 24/08/18 20:52, Vicente Romero wrote: >> Hi, >> >> Please review patch for [1] at [2]. The original issue was reported >> for a combination of a Scala class and a client class written in >> Java. When the Java class was compiled with javac, it couldn't find >> in the class path a class imported by the Scala class, the missing >> class belongs to the Scala standard library. The root issue was that >> the symbol corresponding to the missing Scala class could not be >> completed and a completion exception was thrown. The exception was >> fired while javac was producing the corresponding diagnostic error >> message. Later on the compiler was swallowing the exception, but the >> AST ended up having null fields. This provoked a NPE during a later >> compilation phase. The provided test reproduces the issue using Java >> classes only. >> >> Thanks >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8209173 >> [2] http://cr.openjdk.java.net/~vromero/8209173/webrev.00/ > From john.r.rose at oracle.com Fri Aug 24 22:59:30 2018 From: john.r.rose at oracle.com (John Rose) Date: Fri, 24 Aug 2018 15:59:30 -0700 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream In-Reply-To: <5B7DBC50.4050100@oracle.com> References: <5B7DBC50.4050100@oracle.com> Message-ID: <4BEF2E08-5C36-4D29-8F92-2841FA7B2CD3@oracle.com> What's the story for getting the pathname of the source file? For example, shell shebang files sometimes use ${0} to do this. If we point him to that, then he can reload and recompile the sourcefile for himself. IIRC, the story is "we don't do that', but in that case this request could be viewed as another request for that basic capability for shebang files. I just grepped the shell shebang files in our source base and found that 28 out of 187 of them refer to $0 somehow. Seems to me like a thing shebang files like to do. If we don't support it, maybe that's an RFE worth filing. Of course, I may have forgotten some good reason why we didn't do this, in which case sorry for the noise. ? John On Aug 22, 2018, at 12:41 PM, Jonathan Gibbons wrote: > > Hi Seth, > > The provision of getResourceAsStream and getResource was considered in the implementation of the Source File Launcher feature ... and was dismissed at that time. > > * There are no "normal" resources in the (internal) MemoryClassLoader; there are only the class files generated from the source file. This implies that the provision of these methods in MCL is just for the benefit for folk wanting access to the bytyes for a .class file. (I'm not that that's bad; I'm just saying that is so.) > > * Yes, we could reasonably easily provide getResourceAsStream, but it seems weird to provide getResourceAsStream without also providing an equivalent getResource, but URLs are not (currently) supported for the content of the MemoryClassLoader. Yes, internally, some "fake" URLs are created to keep the API happy, but these are not intended to be used by the end-user, and you'll get an error if you try and open a stream from the URL. I would defer to ClassLoader experts as to whether it is reasonable to provide getResourceAsStream but not getResource. > > It might be reasonable the jdk.compiler module to provide a URLStreamHandlerProvider for these URLs; that would require some consideration. > > -- Jon > > > > On 08/21/2018 11:07 PM, seth lytle wrote: >> i'm working on adding JEP 330 single-file source invocation support to kilim (an ASM-based continuations library for java for which i'm the primary maintainer). we're prepping to promote my fork to the main site and i'd like to be able to support java 11 single-file source invocation as easily as classpath-based invocation, or at least confirm that the differences are intentional >> >> - i need access to the bytecode to weave it at runtime >> - MemoryClassLoader doesn't provide getResourceAsStream >> - it does cache the bytecode, so providing this appears to be easy to implement >> - currently, i access it with a javaagent that mimics MemoryClassLoader.map >> - https://github.com/nqzero/kilim/#java-versions >> - getResource is also missing, and again, much of the plumbing appears to be in place >> - i haven't tried manually building the "memory:///" style urls >> >> an example of my current invocation: >> cp=$(mvn -q dependency:build-classpath -Dmdep.outputFile=/dev/fd/1) >> $java11/bin/java -javaagent:${cp/:*} -cp $cp Xorshift.java >> >> what i'd like to be able to do: >> $java11/bin/java -cp $cp Xorshift.java >> >> >> i saw a previous thread that mentioned getResource in passing but no discussion of whether it was considered (un)desirable. is this feature planned ? are there problems with introducing it ? >> >> >> thanks for the great addition to java - using JEP 330 feels fun >> >> >> >> >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Sat Aug 25 00:47:20 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 24 Aug 2018 17:47:20 -0700 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream In-Reply-To: <4BEF2E08-5C36-4D29-8F92-2841FA7B2CD3@oracle.com> References: <5B7DBC50.4050100@oracle.com> <4BEF2E08-5C36-4D29-8F92-2841FA7B2CD3@oracle.com> Message-ID: John, The worker class that performs the source-file launcher work is passed the name of the source file as an argument, but it is not passed down to the source code or class file in any way. I don't think it makes sense for the compiled code to try and replicate the compilation.? If we accept Seth's use case, it makes more sense to open up getResourceAsStream, and possibly getResource. My hesitation about getResource is that to would always want to have a URLStreamHandler available in jdk.compiler, just for this somewhat obscure (but interesting) use case. -- Jon On 8/24/18 3:59 PM, John Rose wrote: > What's the story for getting the pathname of the source file? > For example, shell shebang files sometimes use ${0} to do this. > If we point him to that, then he can reload and recompile the > sourcefile for himself. ?IIRC, the story is "we don't do that', but > in that case this request could be viewed as another request > for that basic capability for shebang files. > > I just grepped the shell shebang files in our source base and > found that?28 out of 187 of them refer to $0 somehow. ?Seems > to me like a thing shebang files like to do. ?If we don't support it, > maybe that's an RFE worth filing. ?Of course, I may have forgotten > some good reason why we didn't do this, in which case sorry for > the noise. > > ? John > > On Aug 22, 2018, at 12:41 PM, Jonathan Gibbons > > wrote: >> >> Hi Seth, >> >> The provision of getResourceAsStream and getResource was considered >> in the implementation of the Source File Launcher feature ... and was >> dismissed at that time. >> >> * There are no "normal" resources in the (internal) >> MemoryClassLoader; there are only the class files generated from the >> source file. This implies that the provision of these methods in MCL >> is just for the benefit for folk wanting access to the bytyes for a >> .class file. (I'm not that that's bad; I'm just saying that is so.) >> >> * Yes, we could reasonably easily provide getResourceAsStream, but it >> seems weird to provide getResourceAsStream without also providing an >> equivalent getResource, but URLs are not (currently) supported for >> the content of the MemoryClassLoader.? Yes, internally, some "fake" >> URLs are created to keep the API happy, but these are not intended to >> be used by the end-user, and you'll get an error if you try and open >> a stream from the URL.? I would defer to ClassLoader experts as to >> whether it is reasonable to provide getResourceAsStream but not >> getResource. >> >> It might be reasonable the jdk.compiler module to provide a >> URLStreamHandlerProvider for these URLs; that would require some >> consideration. >> >> -- Jon >> >> >> >> On 08/21/2018 11:07 PM, seth lytle wrote: >>> i'm working on adding JEP 330 single-file source invocation support >>> to kilim (an ASM-based continuations library for java for which i'm >>> the primary maintainer). we're prepping to promote my fork to the >>> main site and i'd like to be able to support java 11 single-file >>> source invocation as easily as classpath-based invocation, or at >>> least confirm that the differences are intentional >>> >>> - i need access to the bytecode to weave it at runtime >>> - MemoryClassLoader doesn't provide getResourceAsStream >>> - it does cache the bytecode, so providing this appears to be easy >>> to implement >>> - currently, i access it with a javaagent that mimics >>> MemoryClassLoader.map >>> - https://github.com/nqzero/kilim/#java-versions >>> - getResource is also missing, and again, much of the plumbing >>> appears to be in place >>> - i haven't tried manually building the "memory:///" style urls >>> >>> an example of my current invocation: >>> ? cp=$(mvn -q dependency:build-classpath -Dmdep.outputFile=/dev/fd/1) >>> ? $java11/bin/java -javaagent:${cp/:*} -cp $cp Xorshift.java >>> >>> what i'd like to be able to do: >>> $java11/bin/java -cp $cp Xorshift.java >>> >>> >>> i saw a previous thread that mentioned getResource in passing but no >>> discussion of whether it was considered (un)desirable. is this >>> feature planned ? are there problems with introducing it ? >>> >>> >>> thanks for the great addition to java - using JEP 330 feels fun >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Sat Aug 25 02:27:26 2018 From: john.r.rose at oracle.com (John Rose) Date: Fri, 24 Aug 2018 19:27:26 -0700 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream In-Reply-To: References: <5B7DBC50.4050100@oracle.com> <4BEF2E08-5C36-4D29-8F92-2841FA7B2CD3@oracle.com> Message-ID: <4C68DF1C-04C8-41BE-B339-2ABB38EB6EB7@oracle.com> On Aug 24, 2018, at 5:47 PM, Jonathan Gibbons wrote: > > The worker class that performs the source-file launcher work is > passed the name of the source file as an argument, but it is not > passed down to the source code or class file in any way. > > OK, so that's not a workaround anyway. As a general matter regarding script files, they often make use of $0 to either refer to themselves (for error reporting) or to access side files. The JEP points out that a shell script wrapper can be used to adjust the launching of the JVM, and it occurs to me that (1) this can be used to push the origin (shell "$0") into the Java program, and (2) the JEP allows a single file to be launched by both /bin/sh and the JVM?with a little finicking. Here's a proof of concept: http://cr.openjdk.java.net/~jrose/scripts/myshebang.txt The trick is to make the initial segment of the shebang file acceptable to both /bin/sh and the JVM's source-file reader. I was mildly surprised to find that it can be done with a mix of quotes and comment delimiters (in both languages). Anyway, the above POC might be useful to someone who wants to use the JVM's new source-file mode for a script that needs to refer to itself. I also believe that this shouldn't require a workaround at all, but should be somehow native to the JVM, as $0 is to the shell. So I also filed JDK-8209963 to track this RFE. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Sat Aug 25 04:34:21 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 24 Aug 2018 21:34:21 -0700 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream In-Reply-To: <4C68DF1C-04C8-41BE-B339-2ABB38EB6EB7@oracle.com> References: <5B7DBC50.4050100@oracle.com> <4BEF2E08-5C36-4D29-8F92-2841FA7B2CD3@oracle.com> <4C68DF1C-04C8-41BE-B339-2ABB38EB6EB7@oracle.com> Message-ID: <6d5dc425-7d9a-c836-557b-27552dfc6995@oracle.com> On 8/24/18 7:27 PM, John Rose wrote: > On Aug 24, 2018, at 5:47 PM, Jonathan Gibbons > > wrote: >> >> The worker class that performs the source-file launcher work is >> passed the name of the source file as an argument, but it is not >> passed down to the source code or class file in any way. >> >> > OK, so that's not a workaround anyway. > > As a general matter regarding script files, they often make > use of $0 to either refer to themselves (for error reporting) > or to access side files. ?The JEP points out that a shell script > wrapper can be used to adjust the launching of the JVM, > and it occurs to me that (1) this can be used to push the > origin (shell "$0") into the Java program, and (2) the JEP > allows a single file to be launched by both /bin/sh and the > JVM?with a little finicking. ?Here's a proof of concept: > > http://cr.openjdk.java.net/~jrose/scripts/myshebang.txt > > > The trick is to make the initial segment of the shebang file > acceptable to both /bin/sh and the JVM's source-file reader. > I was mildly surprised to find that it can be done with a mix > of quotes and comment delimiters (in both languages). > > Anyway, the above POC might be useful to someone > who wants to use the JVM's new source-file mode for > a script that needs to refer to itself. > > I also believe that this shouldn't require a workaround at all, > but should be somehow native to the JVM, as $0 is to > the shell. ?So I also filed?JDK-8209963 to?track this RFE. We could define and use a system property with the filename. -- Jon > > ? John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Sat Aug 25 07:00:11 2018 From: john.r.rose at oracle.com (John Rose) Date: Sat, 25 Aug 2018 00:00:11 -0700 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream In-Reply-To: <6d5dc425-7d9a-c836-557b-27552dfc6995@oracle.com> References: <5B7DBC50.4050100@oracle.com> <4BEF2E08-5C36-4D29-8F92-2841FA7B2CD3@oracle.com> <4C68DF1C-04C8-41BE-B339-2ABB38EB6EB7@oracle.com> <6d5dc425-7d9a-c836-557b-27552dfc6995@oracle.com> Message-ID: <4B12AE79-B2B0-414B-9F01-F390934C19DF@oracle.com> On Aug 24, 2018, at 9:34 PM, Jonathan Gibbons wrote: > >> I also believe that this shouldn't require a workaround at all, >> but should be somehow native to the JVM, as $0 is to >> the shell. So I also filed JDK-8209963 to track this RFE. > We could define and use a system property with the filename. Yep. My sample code is designed around the hope that we'd do that someday. At that point, the nasty stuff at the top could be stripped, up to the second shebang "#!", and without the explicit -D options. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Sat Aug 25 14:52:28 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 25 Aug 2018 07:52:28 -0700 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream In-Reply-To: <4B12AE79-B2B0-414B-9F01-F390934C19DF@oracle.com> References: <5B7DBC50.4050100@oracle.com> <4BEF2E08-5C36-4D29-8F92-2841FA7B2CD3@oracle.com> <4C68DF1C-04C8-41BE-B339-2ABB38EB6EB7@oracle.com> <6d5dc425-7d9a-c836-557b-27552dfc6995@oracle.com> <4B12AE79-B2B0-414B-9F01-F390934C19DF@oracle.com> Message-ID: <6c9faca3-6b78-08f6-8760-24cd1273679b@oracle.com> John, A much simpler way to do what you want is to build upon a suggestion that arose during the discussion for this JEP [1]. This is just to use shell scripts and here documents. Here is the example proposed by Stuart, amended to also use a system property for the filename. #!/bin/bash exec java --source 11 -Dsource="$0" /dev/fd/3 "$@" 3< On Aug 24, 2018, at 9:34 PM, Jonathan Gibbons > > wrote: >> >>> I also believe that this shouldn't require a workaround at all, >>> but should be somehow native to the JVM, as $0 is to >>> the shell. ?So I also filed?JDK-8209963 to?track this RFE. >> We could define and use a system property with the filename. > > Yep. ?My sample code is designed around the hope that > we'd do that someday. ?At that point, the nasty stuff at the > top could be stripped, up to the second shebang "#!", > and without the explicit -D options. > > ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From seth.lytle at gmail.com Mon Aug 27 02:11:58 2018 From: seth.lytle at gmail.com (seth lytle) Date: Sun, 26 Aug 2018 22:11:58 -0400 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream In-Reply-To: References: <5B7DBC50.4050100@oracle.com> <4BEF2E08-5C36-4D29-8F92-2841FA7B2CD3@oracle.com> Message-ID: to add to what Jon said, recompiling doesn't necessarily provide the correct info as it may have been manipulated by another agent or classloader (there is a similar weakness in my current workaround) getResourceAsStream (getRAS) is: - robust: you know it's the same bytecode your parent CL used - flexible: you can run woven and unwoven code concurrently - chainable: downstream CLs will see your modifications i haven't been able to think of anything that getResource adds, though some people may use that instead on the core-libs-dev list david lloyd wrote: > Why not go ahead and implement getResource as well? It's not *that* > big of a deal to add a URL handler, and it would be a fairly trivial one. @jon - would you like to reply to that or should i ? my feeling is that we're better off without getResource (getR) - the javadocs appear to allow differences between getR and getRAS - getR adds complexity, startup cost and increases footprint - we're not aware of a consumer of the getR api - the only resource is bytecode, and that's naturally accessed as a stream - many things are changing with java 11 so any bytecode-modifying library is likely to need to make source code changes anyway the only problem i see with not implementing getR is that there's no way to convey to a hypothetical consumer of the API that the bytecode that they're looking for is available via getRAS On Sun, Aug 26, 2018 at 10:10 PM, seth lytle wrote: > to add to what Jon said, recompiling doesn't necessarily provide the > correct info as it may have been manipulated by another agent or > classloader (there is a similar weakness in my current workaround) > > getResourceAsStream (getRAS) is: > - robust: you know it's the same bytecode your parent CL used > - flexible: you can run woven and unwoven code concurrently > - chainable: downstream CLs will see your modifications > > > i haven't been able to think of anything that getResource adds, though > some people may use that instead > > on the core-libs-dev list david lloyd wrote: > > Why not go ahead and implement getResource as well? It's not *that* > > big of a deal to add a URL handler, and it would be a fairly trivial > one. > > > @jon - would you like to reply to that or should i ? > > my feeling is that we're better off without getResource (getR) > - the javadocs appear to allow differences between getR and getRAS > - getR adds complexity, startup cost and increases footprint > - we're not aware of a consumer of the getR api > - the only resource is bytecode, and that's naturally accessed as a stream > - many things are changing with java 11 so any bytecode-modifying library > is likely to need to make source code changes anyway > > the only problem i see with not implementing getR is that there's no way > to convey to a hypothetical consumer of the API that the bytecode that > they're looking for is available via getRAS > > > > > > > > > On Fri, Aug 24, 2018 at 8:47 PM, Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> John, >> >> The worker class that performs the source-file launcher work is >> passed the name of the source file as an argument, but it is not >> passed down to the source code or class file in any way. >> >> I don't think it makes sense for the compiled code to try and replicate >> the compilation. If we accept Seth's use case, it makes more sense >> to open up getResourceAsStream, and possibly getResource. >> My hesitation about getResource is that to would always want to >> have a URLStreamHandler available in jdk.compiler, just for this >> somewhat obscure (but interesting) use case. >> >> -- Jon >> >> On 8/24/18 3:59 PM, John Rose wrote: >> >> What's the story for getting the pathname of the source file? >> For example, shell shebang files sometimes use ${0} to do this. >> If we point him to that, then he can reload and recompile the >> sourcefile for himself. IIRC, the story is "we don't do that', but >> in that case this request could be viewed as another request >> for that basic capability for shebang files. >> >> I just grepped the shell shebang files in our source base and >> found that 28 out of 187 of them refer to $0 somehow. Seems >> to me like a thing shebang files like to do. If we don't support it, >> maybe that's an RFE worth filing. Of course, I may have forgotten >> some good reason why we didn't do this, in which case sorry for >> the noise. >> >> ? John >> >> On Aug 22, 2018, at 12:41 PM, Jonathan Gibbons < >> jonathan.gibbons at oracle.com> wrote: >> >> >> Hi Seth, >> >> The provision of getResourceAsStream and getResource was considered in >> the implementation of the Source File Launcher feature ... and was >> dismissed at that time. >> >> * There are no "normal" resources in the (internal) MemoryClassLoader; >> there are only the class files generated from the source file. This implies >> that the provision of these methods in MCL is just for the benefit for folk >> wanting access to the bytyes for a .class file. (I'm not that that's bad; >> I'm just saying that is so.) >> >> * Yes, we could reasonably easily provide getResourceAsStream, but it >> seems weird to provide getResourceAsStream without also providing an >> equivalent getResource, but URLs are not (currently) supported for the >> content of the MemoryClassLoader. Yes, internally, some "fake" URLs are >> created to keep the API happy, but these are not intended to be used by the >> end-user, and you'll get an error if you try and open a stream from the >> URL. I would defer to ClassLoader experts as to whether it is reasonable >> to provide getResourceAsStream but not getResource. >> >> It might be reasonable the jdk.compiler module to provide a >> URLStreamHandlerProvider for these URLs; that would require some >> consideration. >> >> -- Jon >> >> >> >> On 08/21/2018 11:07 PM, seth lytle wrote: >> >> i'm working on adding JEP 330 single-file source invocation support to >> kilim (an ASM-based continuations library for java for which i'm the >> primary maintainer). we're prepping to promote my fork to the main site >> and i'd like to be able to support java 11 single-file source invocation as >> easily as classpath-based invocation, or at least confirm that the >> differences are intentional >> >> - i need access to the bytecode to weave it at runtime >> - MemoryClassLoader doesn't provide getResourceAsStream >> - it does cache the bytecode, so providing this appears to be easy to >> implement >> - currently, i access it with a javaagent that mimics >> MemoryClassLoader.map >> - https://github.com/nqzero/kilim/#java-versions >> - getResource is also missing, and again, much of the plumbing appears to >> be in place >> - i haven't tried manually building the "memory:///" style urls >> >> an example of my current invocation: >> cp=$(mvn -q dependency:build-classpath -Dmdep.outputFile=/dev/fd/1) >> $java11/bin/java -javaagent:${cp/:*} -cp $cp Xorshift.java >> >> what i'd like to be able to do: >> $java11/bin/java -cp $cp Xorshift.java >> >> >> i saw a previous thread that mentioned getResource in passing but no >> discussion of whether it was considered (un)desirable. is this feature >> planned ? are there problems with introducing it ? >> >> >> thanks for the great addition to java - using JEP 330 feels fun >> >> >> >> >> >> >> >> >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Aug 27 11:14:24 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 27 Aug 2018 12:14:24 +0100 Subject: RFR JDK-8209173: javac fails with completion exception while reporting an error In-Reply-To: <0c0cda58-b305-2ff8-46b8-cf9797f31dea@oracle.com> References: <6d8378f8-a9ed-f99e-7632-2a34b55f8a9a@oracle.com> <0c0cda58-b305-2ff8-46b8-cf9797f31dea@oracle.com> Message-ID: Ok - thanks for the explanation. In general, making rich diagnostic formatter more robust to completion errors seems the right way to go about those things, so I'm ok with the fix. Maurizio On 24/08/18 21:42, Vicente Romero wrote: > > > On 08/24/2018 04:31 PM, Maurizio Cimadamore wrote: >> Hi, >> the fix looks good. If I understand correctly, the issue was that, >> since the diagnostic generation ended up with an exception, the >> diagnostic never really arrived at the speculative attribution >> handler, which meant it was not reported. Correct? > > correct, although at the end it was not the speculative attribution > handler the one that was involved here. I mistakingly thought that, it > was just the default handler, but your still your analysis is correct > >> >> Maurizio > > thanks for the review > Vicente >> >> >> On 24/08/18 20:52, Vicente Romero wrote: >>> Hi, >>> >>> Please review patch for [1] at [2]. The original issue was reported >>> for a combination of a Scala class and a client class written in >>> Java. When the Java class was compiled with javac, it couldn't find >>> in the class path a class imported by the Scala class, the missing >>> class belongs to the Scala standard library. The root issue was that >>> the symbol corresponding to the missing Scala class could not be >>> completed and a completion exception was thrown. The exception was >>> fired while javac was producing the corresponding diagnostic error >>> message. Later on the compiler was swallowing the exception, but the >>> AST ended up having null fields. This provoked a NPE during a later >>> compilation phase. The provided test reproduces the issue using Java >>> classes only. >>> >>> Thanks >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8209173 >>> [2] http://cr.openjdk.java.net/~vromero/8209173/webrev.00/ >> > From vicente.romero at oracle.com Mon Aug 27 12:58:53 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 27 Aug 2018 08:58:53 -0400 Subject: RFR JDK-8209173: javac fails with completion exception while reporting an error In-Reply-To: References: <6d8378f8-a9ed-f99e-7632-2a34b55f8a9a@oracle.com> <0c0cda58-b305-2ff8-46b8-cf9797f31dea@oracle.com> Message-ID: On 08/27/2018 07:14 AM, Maurizio Cimadamore wrote: > Ok - thanks for the explanation. In general, making rich diagnostic > formatter more robust to completion errors seems the right way to go > about those things, so I'm ok with the fix. thanks for the review, > > Maurizio Vicente > > > On 24/08/18 21:42, Vicente Romero wrote: >> >> >> On 08/24/2018 04:31 PM, Maurizio Cimadamore wrote: >>> Hi, >>> the fix looks good. If I understand correctly, the issue was that, >>> since the diagnostic generation ended up with an exception, the >>> diagnostic never really arrived at the speculative attribution >>> handler, which meant it was not reported. Correct? >> >> correct, although at the end it was not the speculative attribution >> handler the one that was involved here. I mistakingly thought that, >> it was just the default handler, but your still your analysis is correct >> >>> >>> Maurizio >> >> thanks for the review >> Vicente >>> >>> >>> On 24/08/18 20:52, Vicente Romero wrote: >>>> Hi, >>>> >>>> Please review patch for [1] at [2]. The original issue was reported >>>> for a combination of a Scala class and a client class written in >>>> Java. When the Java class was compiled with javac, it couldn't find >>>> in the class path a class imported by the Scala class, the missing >>>> class belongs to the Scala standard library. The root issue was >>>> that the symbol corresponding to the missing Scala class could not >>>> be completed and a completion exception was thrown. The exception >>>> was fired while javac was producing the corresponding diagnostic >>>> error message. Later on the compiler was swallowing the exception, >>>> but the AST ended up having null fields. This provoked a NPE during >>>> a later compilation phase. The provided test reproduces the issue >>>> using Java classes only. >>>> >>>> Thanks >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8209173 >>>> [2] http://cr.openjdk.java.net/~vromero/8209173/webrev.00/ >>> >> > From jan.lahoda at oracle.com Mon Aug 27 14:06:39 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 27 Aug 2018 16:06:39 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <3d8d27b0-7bfc-2c26-17b4-53b8bf2abf20@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> <5B64652C.5020000@oracle.com> <5B64BA7A.2010406@oracle.com> <1d6b0189-89a0-7e41-4a04-967383e89400@oracle.com> <5B6C27E9.9050902@oracle.com> <5B6C2C95.5080609@oracle.com> <3d8d27b0-7bfc-2c26-17b4-53b8bf2abf20@oracle.com> Message-ID: <5B84056F.4090000@oracle.com> Hello, Turned out there were some bugs in the last patch: -when parsing constant in rule cases ("case -> ..."), lambda expression parsing is disabled, but the flag that disables lambda expression parsing is cleared for more complicated expressions like "case a + a -> ...". The proposed patch tweaks the JavacParser to preserve the flag when parsing mode changes. The test (RuleParsingTest) intentionally tests also expressions that are not constants, to ensure error recovery can handle them. -when the expression in a value break is a lambda, it is not processed by LambdaToMethod properly. Fixed by a tweak to TreeTranslator to also translate value breaks A patch that fixes these problems, and also adds tests for variable scopes in switches with rule cases is here: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.05/ Delta webrev from previous version: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.04.05/ Any feedback is welcome! Thanks, Jan On 9.8.2018 14:53, Maurizio Cimadamore wrote: > Looks good. > > Maurizio > > > On 09/08/18 12:59, Jan Lahoda wrote: >> One more tiny change to tests to fix a failure on Windows (I apologize >> for not folding that into the previous update): >> webrev: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.04/ >> delta from previous (webrev.03): >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.03.04/ >> >> Thanks, >> Jan >> >> On 9.8.2018 13:39, Jan Lahoda wrote: >>> On 3.8.2018 22:39, Maurizio Cimadamore wrote: >>>> Looks good - when I eyeballed compiler.properties earlier I missed >>>> this: >>>> >>>> "value break not supported in 'enhanced for' " >>>> >>>> I understand why you get 'enhanced for', not sure that adds value >>>> w.r.t. >>>> just 'for'. I don't have a strong opinion. >>> >>> Sounds reasonable, I've updated the compiler.properties, and added one >>> more test for SimpleTreeVisitor. >>> >>> An updated patch is here: >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.03/ >>> >>> delta from the previous revision: >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.02.03/ >>> >>> Diagnostics: >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.03/diags.html >>> >>> Thanks, >>> Jan >>> >>>> >>>> Maurizio >>>> >>>> >>>> On 03/08/18 21:26, Jan Lahoda wrote: >>>>> On 3.8.2018 16:22, Jan Lahoda wrote: >>>>>> On 3.8.2018 15:47, Maurizio Cimadamore wrote: >>>>>>> I like the diagnostic changes, and the API change - I think it's >>>>>>> more >>>>>>> consistent now - thanks for taking a second look. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> I've forgot to include the generated examples for this update, so >>>>>> I've >>>>>> placed it here: >>>>>> file:///usr/local/home/lahvac/src/jdk/cr.openjdk.java.net/8192963/webrev.02/diags.html >>>>>> >>>>>> >>>>>> >>>>> >>>>> I apologize for a wrong link, the correct one is: >>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/diags.html >>>>> >>>>> Jan >>>>> >>>>>> >>>>>> >>>>>> Jan >>>>>> >>>>>>> >>>>>>> Thumbs up. >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> >>>>>>> On 03/08/18 14:35, Jan Lahoda wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Thanks for all the comments. An updated patch is here: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/ >>>>>>>> Changes against the previous revision: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.01.02/ >>>>>>>> >>>>>>>> Updated specdiff: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/api.diff.02/overview-summary.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Any feedback is welcome. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jan >>>>>>>> >>>>>>>> On 1.8.2018 18:39, Maurizio Cimadamore wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 01/08/18 16:43, Jan Lahoda wrote: >>>>>>>>>> Hi Maurizio, >>>>>>>>>> >>>>>>>>>> Thanks for the comments - responses are inlined. >>>>>>>>>> >>>>>>>>>> On 1.8.2018 16:04, Maurizio Cimadamore wrote: >>>>>>>>>>> Hi Jan, >>>>>>>>>>> great work, some comments below. >>>>>>>>>>> >>>>>>>>>>> * Diagnostics. I see that some diagnostics seem to be >>>>>>>>>>> inconsistent >>>>>>>>>>> with >>>>>>>>>>> what we do for 'return' - e.g. javac diagnostics for 'return' >>>>>>>>>>> are >>>>>>>>>>> quite >>>>>>>>>>> succint: >>>>>>>>>>> >>>>>>>>>>> - "return outside method" >>>>>>>>>>> >>>>>>>>>>> - "missing return statement" >>>>>>>>>>> >>>>>>>>>>> - "unexpected return value" >>>>>>>>>>> >>>>>>>>>>> - "error: incompatible types: String cannot be converted to int" >>>>>>>>>>> >>>>>>>>>>> The analogous conditions for break in switch expression seem >>>>>>>>>>> to be >>>>>>>>>>> more >>>>>>>>>>> verbose: >>>>>>>>>>> >>>>>>>>>>> - "expression break not immediately enclosed by a switch >>>>>>>>>>> expression" >>>>>>>>>> >>>>>>>>>> I think the closest error to "return outside method" is "value >>>>>>>>>> break >>>>>>>>>> outside of switch expression". The "expression break not >>>>>>>>>> immediately >>>>>>>>>> enclosed by a switch expression" is used when the break is inside >>>>>>>>>> another breakable statement inside the switch expression. I guess >>>>>>>>>> this >>>>>>>>>> should be rephrased at least to "value break not immediately >>>>>>>>>> enclosed >>>>>>>>>> by switch expression". >>>>>>>>>> >>>>>>>>> Fine, but do we need two distinct errors? Or do we need maybe the >>>>>>>>> same >>>>>>>>> error and an extra detail string at the bottom for the 'you are >>>>>>>>> inside a >>>>>>>>> switch expr, but there's some other breaky context in between' >>>>>>>>> condition? >>>>>>>>>>> >>>>>>>>>>> - "break is missing a value to return from switch expression" >>>>>>>>>> >>>>>>>>>> How about >>>>>>>>>> "missing break value"? >>>>>>>>>> >>>>>>>>>> (the break is present, but the value is missing.) >>>>>>>>> I'm fine with that! >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - There's no equivalent for the third above - probably the >>>>>>>>>>> closest >>>>>>>>>>> condition would be to 'break expr' from a switch statement, in >>>>>>>>>>> which >>>>>>>>>>> case I bet you get a 'missing label' error - should we rectify >>>>>>>>>>> that >>>>>>>>>>> too? >>>>>>>>>> >>>>>>>>>> There are several conditions, and the error differ, consider: >>>>>>>>>> --- >>>>>>>>>> public class SwitchExpr { >>>>>>>>>> private void breakTest(int e) { >>>>>>>>>> break ; >>>>>>>>>> break x; >>>>>>>>>> break (e); >>>>>>>>>> while (true) { >>>>>>>>>> break x; >>>>>>>>>> break (e); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> This gives: >>>>>>>>>> --- >>>>>>>>>> SwitchExpr.java:3: error: break outside switch or loop >>>>>>>>>> break ; >>>>>>>>>> ^ >>>>>>>>>> SwitchExpr.java:4: error: undefined label: x >>>>>>>>>> break x; >>>>>>>>>> ^ >>>>>>>>>> SwitchExpr.java:5: error: value break outside of switch >>>>>>>>>> expression >>>>>>>>>> break (e); >>>>>>>>>> ^ >>>>>>>>>> SwitchExpr.java:7: error: undefined label: x >>>>>>>>>> break x; >>>>>>>>>> ^ >>>>>>>>>> SwitchExpr.java:8: error: value break outside of switch >>>>>>>>>> expression >>>>>>>>>> break (e); >>>>>>>>>> ^ >>>>>>>>>> 5 errors >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> So when it is clear the break is a value break, a value break >>>>>>>>>> related >>>>>>>>>> diagnostic is reported, otherwise, the errors fall back to the >>>>>>>>>> existing diagnostics of cannot find labels. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - "incompatible types: bad type in switch expression" >>>>>>>>>>> ... >>>>>>>>>>> (A cannot be converted to B) >>>>>>>>>> >>>>>>>>>> I think this was modelled based on conditional expressions: >>>>>>>>>> SwitchExpr.java:10: error: incompatible types: bad type in >>>>>>>>>> conditional >>>>>>>>>> expression >>>>>>>>>> B b = e == 0 ? (A) null : (B) null; >>>>>>>>>> ^ >>>>>>>>>> A cannot be converted to B >>>>>>>>>> >>>>>>>>>> I'll look if this can be changed. >>>>>>>>> I see, I'm not a big fan of the conditional expression nesting too >>>>>>>>> - I >>>>>>>>> think the important part is 'A != B' and it should be put front >>>>>>>>> and >>>>>>>>> center. That said, this is not a blocking issue, and I'm ok with a >>>>>>>>> followup. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Not sure whether we should try to maintain the same style across >>>>>>>>>>> break/return, but it seemed worth at least pointing out. >>>>>>>>>>> >>>>>>>>>>> Other diagnostic comments: >>>>>>>>>>> >>>>>>>>>>> - "error: j is ambiguously both a valid expression and a valid >>>>>>>>>>> label" - >>>>>>>>>>> this seems convoluted, I would personally rephrase as something >>>>>>>>>>> like: >>>>>>>>>>> >>>>>>>>>>> ambiguous reference to 'j' >>>>>>>>>>> ... >>>>>>>>>>> ('j' is both a label and an expression) >>>>>>>>>> >>>>>>>>>> Will done. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - "break is jumping outside of the enclosing switch >>>>>>>>>>> expression" -> >>>>>>>>>>> "break outside of enclosing switch expression" >>>>>>>>>> >>>>>>>>>> Will do. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - "continue is jumping outside of the enclosing switch >>>>>>>>>>> expression" -> >>>>>>>>>>> "continue outside of enclosing switch expression" >>>>>>>>>> >>>>>>>>>> Will do. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> * Attr - The refactoring of switchExpr into switch + >>>>>>>>>>> handleSwitch is >>>>>>>>>>> very sweet - I like it! >>>>>>>>>>> >>>>>>>>>>> * Flow - a bit odd that we have to make up a new tree to call >>>>>>>>>>> recordExit >>>>>>>>>>> - but I see why you're doing it :-) >>>>>>>>>>> >>>>>>>>>>> * Lower - it would be nice to have a comment on SwitchExpression >>>>>>>>>>> that >>>>>>>>>>> shows what the generated code shape looks like; I think we do >>>>>>>>>>> that >>>>>>>>>>> for >>>>>>>>>>> other non-trivial translations (e.g. for each) >>>>>>>>>> >>>>>>>>>> Will do. >>>>>>>>> Thanks >>>>>>>>> Maurizio >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> * ExpSwitchNestingTest - I see that this test is not using the >>>>>>>>>>> newer >>>>>>>>>>> combo framework. Actually, I'm not even sure this one needs any >>>>>>>>>>> templating logic at all, as it seems the test is doing its own >>>>>>>>>>> replacements. But I was going to note that this test is not >>>>>>>>>>> using the >>>>>>>>>>> shared context enhancements, which I guess it's still ok >>>>>>>>>>> given the >>>>>>>>>>> number of combinations checked is low. Maybe worth keeping an >>>>>>>>>>> eye on >>>>>>>>>>> this in the future, should we keep adding new cases to it. >>>>>>>>>>> >>>>>>>>>>> Maurizio >>>>>>>>>>> >>>>>>>>>>> On 01/08/18 07:28, Jan Lahoda wrote: >>>>>>>>>>>> Hi Jon, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the comments! >>>>>>>>>>>> >>>>>>>>>>>> An updated webrev that reflects the comments is here: >>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> A delta webrev between this webrev and the webrev.00 is here: >>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ >>>>>>>>>>>> >>>>>>>>>>>> Does this look better? >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> Jan >>>>>>>>>>>> >>>>>>>>>>>> On 28.7.2018 01:12, Jonathan Gibbons wrote: >>>>>>>>>>>>> CaseTree.java:52: spelling, "lables" >>>>>>>>>>>>> >>>>>>>>>>>>> CaseTree.java:84: "return" should be "returns". >>>>>>>>>>>>> >>>>>>>>>>>>> Lots of @Deprecated annotations without corresponding >>>>>>>>>>>>> @deprecated >>>>>>>>>>>>> javadoc tag. >>>>>>>>>>>>> Should the @apiNote really be @deprecated. I also think that >>>>>>>>>>>>> using >>>>>>>>>>>>> @Deprecated >>>>>>>>>>>>> like this is "a bit smelly", and had a discussion with Stuart >>>>>>>>>>>>> "Dr >>>>>>>>>>>>> Deprecator" regarding >>>>>>>>>>>>> my concerns. If nothing else, assuming the feature is a >>>>>>>>>>>>> success, we >>>>>>>>>>>>> are >>>>>>>>>>>>> setting up >>>>>>>>>>>>> a precedent of marking an API as deprecated-for-removal, and >>>>>>>>>>>>> then >>>>>>>>>>>>> in the >>>>>>>>>>>>> next >>>>>>>>>>>>> release, simply removing the annotation. >>>>>>>>>>>>> >>>>>>>>>>>>> Attr.java:1482: ugly use of @SuppressWarnings. I understand >>>>>>>>>>>>> why >>>>>>>>>>>>> it is >>>>>>>>>>>>> there, >>>>>>>>>>>>> but it exemplifies why @Deprecated on the declaration is a bad >>>>>>>>>>>>> idea. >>>>>>>>>>>>> It'll be too easy to not remove these annotations in JDK 13. >>>>>>>>>>>>> >>>>>>>>>>>>> Attr:1825: why XXX >>>>>>>>>>>>> >>>>>>>>>>>>> LambdaToMethod: unnecessary new import, CaseKind >>>>>>>>>>>>> Flow: unnecessary new import, CaseKind >>>>>>>>>>>>> >>>>>>>>>>>>> JavacParser: order of imports >>>>>>>>>>>>> >>>>>>>>>>>>> messages: generally, I think the text of the messages could be >>>>>>>>>>>>> improved >>>>>>>>>>>>> (related but not new) we should somehow identify language >>>>>>>>>>>>> keywords >>>>>>>>>>>>> from >>>>>>>>>>>>> English text (i.e. words like `break, `case`, `continue`, >>>>>>>>>>>>> `return`) >>>>>>>>>>>>> 204: saying the name is both a valid label and a valid >>>>>>>>>>>>> expression >>>>>>>>>>>>> hints >>>>>>>>>>>>> at the cause but not the error (i.e. the name is ambiguous) >>>>>>>>>>>>> >>>>>>>>>>>>> JCTree: inconsistent layout of annotations; inconsistent >>>>>>>>>>>>> use of >>>>>>>>>>>>> @Deprecated and @Deprecated(forRemoval=true) >>>>>>>>>>>>> >>>>>>>>>>>>> (tests) >>>>>>>>>>>>> Not reviewed in detail yet. >>>>>>>>>>>>> New test descriptions should use "/*" for jtreg comment block; >>>>>>>>>>>>> not >>>>>>>>>>>>> "/**". These are not javadoc documentation comments. >>>>>>>>>>>>> New test descriptions should have @summary >>>>>>>>>>>>> Presumably, we will have to change the -old.out files if the >>>>>>>>>>>>> preview >>>>>>>>>>>>> feature becomes standard in JDK 13. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Overall, >>>>>>>>>>>>> >>>>>>>>>>>>> The logic is nice, but the use of @Deprecated(forRemoval=true) >>>>>>>>>>>>> and >>>>>>>>>>>>> resulting @SuppressWarnings really suck. >>>>>>>>>>>>> I don't think the current practice is serving us well. >>>>>>>>>>>>> >>>>>>>>>>>>> -- Jon >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> As JEP 325 is in the proposed to target state, I thought it >>>>>>>>>>>>>> might >>>>>>>>>>>>>> be a >>>>>>>>>>>>>> good idea to start a review process for the code. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The code here strives to implement the current specification >>>>>>>>>>>>>> for >>>>>>>>>>>>>> the >>>>>>>>>>>>>> Switch Expressions: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> The current webrev is here: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> (includes a list of new errors.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> JBS: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>>>>>>>>>>>>> >>>>>>>>>>>>>> CSRs: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any feedback is welcome! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Jan >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>> > From maurizio.cimadamore at oracle.com Mon Aug 27 14:07:45 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 27 Aug 2018 15:07:45 +0100 Subject: RFR 8209064: Make intellij support more robust after changes for 2018.2 In-Reply-To: References: <63022bb6-5a5e-8b34-b73f-a7f7a368f8f4@oracle.com> <698c5ed2-604a-2425-a867-5bfbfa897c3b@oracle.com> Message-ID: <9666fa9e-d38c-aa34-8ab3-2489a2defc58@oracle.com> As I was about to push this, I realize there was a minor nit with the way in which build.xml files found some classes inside the generated .idea folder - that is, the path to this folder was defined in a relative way from the location of the script file. A more robust way to get there is to setup an idea.dir ant variable which is dynamically populated by the IDE with the known location of the project IML file. The only files touched were the two project build.xml files, as well as the idea ant.xml files. Webrev: http://cr.openjdk.java.net/~mcimadamore/8209064_v2 Maurizio On 23/08/18 14:21, Maurizio Cimadamore wrote: > > > On 21/08/18 10:31, Magnus Ihse Bursie wrote: >> Hi Maurizio! >> >> Even if this only incidentally relates to the build, please always >> include build-dev when making changes in the "make" directory. > I will - thanks >> >> As far as I can understand, your changes looks good. One question: >> the build.xml was previously stored as a "template", and copied to >> the output directory. Now it's left in the source tree. I assume that >> there was no actual transformations or changes made to the template >> before? So that the scripts do not modify the source tree version, >> that is. > You are correct - the script is not meant to be modified; customized > properties are injected by the runtime environment - such properties > are defined in the ant.xml file and that is indeed a template file (so > it can be customized). > > Thanks > Maurizio >> >> /Magnus >> >> On 2018-08-07 13:21, Maurizio Cimadamore wrote: >>> Hi, >>> last week I submitted an 'emergency' patch to fix intellij project >>> support after 2018.2 changes. The goal of these changes was to move >>> the build.xml ant file out of the .idea folder, as the IDE no longer >>> supported DOM indexing in such folders (as a result of >>> https://youtrack.jetbrains.com/issue/IDEA-189915). As a workaround, >>> I tweaked the scripts to copy build.xml in the build folder. >>> >>> Thinking more about this issue, there's a more robust fix possible, >>> which doesn't involve moving files to the build folder (which could >>> be potentially unreliable, depending on how people build the JDK). >>> In fact, the best solution is to leave build.xml where it is, and >>> fix the remaining configuration files to point at it. This allows to >>> revert all changes in the scripts that set up the project >>> configuration (bin/idea.sh for JDK, and make/langtools/build.xml for >>> langtools). >>> >>> For the langtools project a bit more changes were necessary, given >>> that in langtools we did not have a 'template' folder - and all >>> intellij files were dumped onto the same path. So I had to move the >>> configuration langtools files (all but build.xml) under a new >>> template folder (located under make/langtools/intellij/make) and >>> place build.xml outside it. Then tweak the build.xml script to work >>> off this new template folder. These are all small conceptual >>> changes, but the impact on the webrev is quite biggie (because of >>> file renaming etc.). >>> >>> I also took the chance to fix some issues with the JDK project ANT >>> configuration (see changes in make/idea/template/workspace.xml), as >>> the last changes did not update the location of the ant file used >>> here - as a result no ant target entries were showing up under the >>> Build menu. >>> >>> Webrev here: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8209064/ >>> >>> Cheers >>> Maurizio >>> >> > From maurizio.cimadamore at oracle.com Mon Aug 27 14:32:31 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 27 Aug 2018 15:32:31 +0100 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B84056F.4090000@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> <5B64652C.5020000@oracle.com> <5B64BA7A.2010406@oracle.com> <1d6b0189-89a0-7e41-4a04-967383e89400@oracle.com> <5B6C27E9.9050902@oracle.com> <5B6C2C95.5080609@oracle.com> <3d8d27b0-7bfc-2c26-17b4-53b8bf2abf20@oracle.com> <5B84056F.4090000@oracle.com> Message-ID: <58e9e825-a027-f1fb-8b59-48bd16caffd8@oracle.com> Sensible fixes - generally looks good. The change to analyzeParens? is subtle - that is, if you see something like (x) -> ..., that logic would reasonably conclude that the parenthesis corresponds to an implicit lambda decl - so parser would attempt to go there, which at first seems sensible. But in reality, when inside a 'case' you really want the compiler to process a (x) followed by an arrow (->), where the former is the (parenthesized) constant expression and the latter is the CASE arrow. But, one followup question is: what happens with this? case (x, y) -> 42 I believe your patch now classify this as a parenthesized expression, which probably generates several downstream errors? Maurizio On 27/08/18 15:06, Jan Lahoda wrote: > Hello, > > Turned out there were some bugs in the last patch: > -when parsing constant in rule cases ("case -> ..."), > lambda expression parsing is disabled, but the flag that disables > lambda expression parsing is cleared for more complicated expressions > like "case a + a -> ...". The proposed patch tweaks the JavacParser to > preserve the flag when parsing mode changes. The test > (RuleParsingTest) intentionally tests also expressions that are not > constants, to ensure error recovery can handle them. > > -when the expression in a value break is a lambda, it is not processed > by LambdaToMethod properly. Fixed by a tweak to TreeTranslator to also > translate value breaks > > A patch that fixes these problems, and also adds tests for variable > scopes in switches with rule cases is here: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.05/ > > Delta webrev from previous version: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.04.05/ > > Any feedback is welcome! > > Thanks, > ??? Jan > > On 9.8.2018 14:53, Maurizio Cimadamore wrote: >> Looks good. >> >> Maurizio >> >> >> On 09/08/18 12:59, Jan Lahoda wrote: >>> One more tiny change to tests to fix a failure on Windows (I apologize >>> for not folding that into the previous update): >>> webrev: >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.04/ >>> delta from previous (webrev.03): >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.03.04/ >>> >>> Thanks, >>> ??? Jan >>> >>> On 9.8.2018 13:39, Jan Lahoda wrote: >>>> On 3.8.2018 22:39, Maurizio Cimadamore wrote: >>>>> Looks good - when I eyeballed compiler.properties earlier I missed >>>>> this: >>>>> >>>>> "value break not supported in 'enhanced for' " >>>>> >>>>> I understand why you get 'enhanced for', not sure that adds value >>>>> w.r.t. >>>>> just 'for'. I don't have a strong opinion. >>>> >>>> Sounds reasonable, I've updated the compiler.properties, and added one >>>> more test for SimpleTreeVisitor. >>>> >>>> An updated patch is here: >>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.03/ >>>> >>>> delta from the previous revision: >>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.02.03/ >>>> >>>> Diagnostics: >>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.03/diags.html >>>> >>>> Thanks, >>>> ???? Jan >>>> >>>>> >>>>> Maurizio >>>>> >>>>> >>>>> On 03/08/18 21:26, Jan Lahoda wrote: >>>>>> On 3.8.2018 16:22, Jan Lahoda wrote: >>>>>>> On 3.8.2018 15:47, Maurizio Cimadamore wrote: >>>>>>>> I like the diagnostic changes, and the API change - I think it's >>>>>>>> more >>>>>>>> consistent now - thanks for taking a second look. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> I've forgot to include the generated examples for this update, so >>>>>>> I've >>>>>>> placed it here: >>>>>>> file:///usr/local/home/lahvac/src/jdk/cr.openjdk.java.net/8192963/webrev.02/diags.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> I apologize for a wrong link, the correct one is: >>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/diags.html >>>>>> >>>>>> Jan >>>>>> >>>>>>> >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>>> >>>>>>>> Thumbs up. >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> >>>>>>>> On 03/08/18 14:35, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Thanks for all the comments. An updated patch is here: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/ >>>>>>>>> Changes against the previous revision: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.01.02/ >>>>>>>>> >>>>>>>>> Updated specdiff: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/api.diff.02/overview-summary.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Any feedback is welcome. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> ??? Jan >>>>>>>>> >>>>>>>>> On 1.8.2018 18:39, Maurizio Cimadamore wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 01/08/18 16:43, Jan Lahoda wrote: >>>>>>>>>>> Hi Maurizio, >>>>>>>>>>> >>>>>>>>>>> Thanks for the comments - responses are inlined. >>>>>>>>>>> >>>>>>>>>>> On 1.8.2018 16:04, Maurizio Cimadamore wrote: >>>>>>>>>>>> Hi Jan, >>>>>>>>>>>> great work, some comments below. >>>>>>>>>>>> >>>>>>>>>>>> * Diagnostics. I see that some diagnostics seem to be >>>>>>>>>>>> inconsistent >>>>>>>>>>>> with >>>>>>>>>>>> what we do for 'return' - e.g. javac diagnostics for 'return' >>>>>>>>>>>> are >>>>>>>>>>>> quite >>>>>>>>>>>> succint: >>>>>>>>>>>> >>>>>>>>>>>> - "return outside method" >>>>>>>>>>>> >>>>>>>>>>>> - "missing return statement" >>>>>>>>>>>> >>>>>>>>>>>> - "unexpected return value" >>>>>>>>>>>> >>>>>>>>>>>> - "error: incompatible types: String cannot be converted to >>>>>>>>>>>> int" >>>>>>>>>>>> >>>>>>>>>>>> The analogous conditions for break in switch expression seem >>>>>>>>>>>> to be >>>>>>>>>>>> more >>>>>>>>>>>> verbose: >>>>>>>>>>>> >>>>>>>>>>>> - "expression break not immediately enclosed by a switch >>>>>>>>>>>> expression" >>>>>>>>>>> >>>>>>>>>>> I think the closest error to "return outside method" is "value >>>>>>>>>>> break >>>>>>>>>>> outside of switch expression". The "expression break not >>>>>>>>>>> immediately >>>>>>>>>>> enclosed by a switch expression" is used when the break is >>>>>>>>>>> inside >>>>>>>>>>> another breakable statement inside the switch expression. I >>>>>>>>>>> guess >>>>>>>>>>> this >>>>>>>>>>> should be rephrased at least to "value break not immediately >>>>>>>>>>> enclosed >>>>>>>>>>> by switch expression". >>>>>>>>>>> >>>>>>>>>> Fine, but do we need two distinct errors? Or do we need maybe >>>>>>>>>> the >>>>>>>>>> same >>>>>>>>>> error and an extra detail string at the bottom for the 'you are >>>>>>>>>> inside a >>>>>>>>>> switch expr, but there's some other breaky context in between' >>>>>>>>>> condition? >>>>>>>>>>>> >>>>>>>>>>>> - "break is missing a value to return from switch expression" >>>>>>>>>>> >>>>>>>>>>> How about >>>>>>>>>>> "missing break value"? >>>>>>>>>>> >>>>>>>>>>> (the break is present, but the value is missing.) >>>>>>>>>> I'm fine with that! >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - There's no equivalent for the third above - probably the >>>>>>>>>>>> closest >>>>>>>>>>>> condition would be to 'break expr' from a switch statement, in >>>>>>>>>>>> which >>>>>>>>>>>> case I bet you get a 'missing label' error - should we rectify >>>>>>>>>>>> that >>>>>>>>>>>> too? >>>>>>>>>>> >>>>>>>>>>> There are several conditions, and the error differ, consider: >>>>>>>>>>> --- >>>>>>>>>>> public class SwitchExpr { >>>>>>>>>>> ????? private void breakTest(int e) { >>>>>>>>>>> ????????? break ; >>>>>>>>>>> ????????? break x; >>>>>>>>>>> ????????? break (e); >>>>>>>>>>> ????????? while (true) { >>>>>>>>>>> ?????????????? break x; >>>>>>>>>>> ?????????????? break (e); >>>>>>>>>>> ????????? } >>>>>>>>>>> ????? } >>>>>>>>>>> } >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> This gives: >>>>>>>>>>> --- >>>>>>>>>>> SwitchExpr.java:3: error: break outside switch or loop >>>>>>>>>>> ????????? break ; >>>>>>>>>>> ????????? ^ >>>>>>>>>>> SwitchExpr.java:4: error: undefined label: x >>>>>>>>>>> ????????? break x; >>>>>>>>>>> ????????? ^ >>>>>>>>>>> SwitchExpr.java:5: error: value break outside of switch >>>>>>>>>>> expression >>>>>>>>>>> ????????? break (e); >>>>>>>>>>> ????????? ^ >>>>>>>>>>> SwitchExpr.java:7: error: undefined label: x >>>>>>>>>>> ?????????????? break x; >>>>>>>>>>> ?????????????? ^ >>>>>>>>>>> SwitchExpr.java:8: error: value break outside of switch >>>>>>>>>>> expression >>>>>>>>>>> ?????????????? break (e); >>>>>>>>>>> ?????????????? ^ >>>>>>>>>>> 5 errors >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> So when it is clear the break is a value break, a value break >>>>>>>>>>> related >>>>>>>>>>> diagnostic is reported, otherwise, the errors fall back to the >>>>>>>>>>> existing diagnostics of cannot find labels. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - "incompatible types: bad type in switch expression" >>>>>>>>>>>> ... >>>>>>>>>>>> (A cannot be converted to B) >>>>>>>>>>> >>>>>>>>>>> I think this was modelled based on conditional expressions: >>>>>>>>>>> SwitchExpr.java:10: error: incompatible types: bad type in >>>>>>>>>>> conditional >>>>>>>>>>> expression >>>>>>>>>>> ????????? B b = e == 0 ? (A) null : (B) null; >>>>>>>>>>> ???????????????????????? ^ >>>>>>>>>>> ??? A cannot be converted to B >>>>>>>>>>> >>>>>>>>>>> I'll look if this can be changed. >>>>>>>>>> I see, I'm not a big fan of the conditional expression >>>>>>>>>> nesting too >>>>>>>>>> - I >>>>>>>>>> think the important part is 'A != B' and it should be put front >>>>>>>>>> and >>>>>>>>>> center. That said, this is not a blocking issue, and I'm ok >>>>>>>>>> with a >>>>>>>>>> followup. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Not sure whether we should try to maintain the same style >>>>>>>>>>>> across >>>>>>>>>>>> break/return, but it seemed worth at least pointing out. >>>>>>>>>>>> >>>>>>>>>>>> Other diagnostic comments: >>>>>>>>>>>> >>>>>>>>>>>> - "error: j is ambiguously both a valid expression and a valid >>>>>>>>>>>> label" - >>>>>>>>>>>> this seems convoluted, I would personally rephrase as >>>>>>>>>>>> something >>>>>>>>>>>> like: >>>>>>>>>>>> >>>>>>>>>>>> ambiguous reference to 'j' >>>>>>>>>>>> ... >>>>>>>>>>>> ('j' is both a label and an expression) >>>>>>>>>>> >>>>>>>>>>> Will done. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - "break is jumping outside of the enclosing switch >>>>>>>>>>>> expression" -> >>>>>>>>>>>> "break outside of enclosing switch expression" >>>>>>>>>>> >>>>>>>>>>> Will do. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - "continue is jumping outside of the enclosing switch >>>>>>>>>>>> expression" -> >>>>>>>>>>>> "continue outside of enclosing switch expression" >>>>>>>>>>> >>>>>>>>>>> Will do. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> * Attr - The refactoring of switchExpr into switch + >>>>>>>>>>>> handleSwitch is >>>>>>>>>>>> very sweet - I like it! >>>>>>>>>>>> >>>>>>>>>>>> * Flow - a bit odd that we have to make up a new tree to call >>>>>>>>>>>> recordExit >>>>>>>>>>>> - but I see why you're doing it :-) >>>>>>>>>>>> >>>>>>>>>>>> * Lower - it would be nice to have a comment on >>>>>>>>>>>> SwitchExpression >>>>>>>>>>>> that >>>>>>>>>>>> shows what the generated code shape looks like; I think we do >>>>>>>>>>>> that >>>>>>>>>>>> for >>>>>>>>>>>> other non-trivial translations (e.g. for each) >>>>>>>>>>> >>>>>>>>>>> Will do. >>>>>>>>>> Thanks >>>>>>>>>> Maurizio >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> ??? Jan >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> * ExpSwitchNestingTest - I see that this test is not using the >>>>>>>>>>>> newer >>>>>>>>>>>> combo framework. Actually, I'm not even sure this one needs >>>>>>>>>>>> any >>>>>>>>>>>> templating logic at all, as it seems the test is doing its own >>>>>>>>>>>> replacements. But I was going to note that this test is not >>>>>>>>>>>> using the >>>>>>>>>>>> shared context enhancements, which I guess it's still ok >>>>>>>>>>>> given the >>>>>>>>>>>> number of combinations checked is low. Maybe worth keeping an >>>>>>>>>>>> eye on >>>>>>>>>>>> this in the future, should we keep adding new cases to it. >>>>>>>>>>>> >>>>>>>>>>>> Maurizio >>>>>>>>>>>> >>>>>>>>>>>> On 01/08/18 07:28, Jan Lahoda wrote: >>>>>>>>>>>>> Hi Jon, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the comments! >>>>>>>>>>>>> >>>>>>>>>>>>> An updated webrev that reflects the comments is here: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> A delta webrev between this webrev and the webrev.00 is here: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Does this look better? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>> Jan >>>>>>>>>>>>> >>>>>>>>>>>>> On 28.7.2018 01:12, Jonathan Gibbons wrote: >>>>>>>>>>>>>> CaseTree.java:52: spelling, "lables" >>>>>>>>>>>>>> >>>>>>>>>>>>>> CaseTree.java:84:? "return" should be "returns". >>>>>>>>>>>>>> >>>>>>>>>>>>>> Lots of @Deprecated annotations without corresponding >>>>>>>>>>>>>> @deprecated >>>>>>>>>>>>>> javadoc tag. >>>>>>>>>>>>>> Should the @apiNote really be @deprecated. I also think that >>>>>>>>>>>>>> using >>>>>>>>>>>>>> @Deprecated >>>>>>>>>>>>>> like this is "a bit smelly", and had a discussion with >>>>>>>>>>>>>> Stuart >>>>>>>>>>>>>> "Dr >>>>>>>>>>>>>> Deprecator" regarding >>>>>>>>>>>>>> my concerns. If nothing else, assuming the feature is a >>>>>>>>>>>>>> success, we >>>>>>>>>>>>>> are >>>>>>>>>>>>>> setting up >>>>>>>>>>>>>> a precedent of marking an API as deprecated-for-removal, and >>>>>>>>>>>>>> then >>>>>>>>>>>>>> in the >>>>>>>>>>>>>> next >>>>>>>>>>>>>> release, simply removing the annotation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Attr.java:1482: ugly use of @SuppressWarnings. I understand >>>>>>>>>>>>>> why >>>>>>>>>>>>>> it is >>>>>>>>>>>>>> there, >>>>>>>>>>>>>> but it exemplifies why @Deprecated on the declaration is >>>>>>>>>>>>>> a bad >>>>>>>>>>>>>> idea. >>>>>>>>>>>>>> It'll be too easy to not remove these annotations in JDK 13. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Attr:1825: why XXX >>>>>>>>>>>>>> >>>>>>>>>>>>>> LambdaToMethod: unnecessary new import, CaseKind >>>>>>>>>>>>>> Flow: unnecessary new import, CaseKind >>>>>>>>>>>>>> >>>>>>>>>>>>>> JavacParser: order of imports >>>>>>>>>>>>>> >>>>>>>>>>>>>> messages: generally, I think the text of the messages >>>>>>>>>>>>>> could be >>>>>>>>>>>>>> improved >>>>>>>>>>>>>> (related but not new) we should somehow identify language >>>>>>>>>>>>>> keywords >>>>>>>>>>>>>> from >>>>>>>>>>>>>> English text (i.e. words like `break, `case`, `continue`, >>>>>>>>>>>>>> `return`) >>>>>>>>>>>>>> 204: saying the name is both a valid label and a valid >>>>>>>>>>>>>> expression >>>>>>>>>>>>>> hints >>>>>>>>>>>>>> at the cause but not the error (i.e. the name is ambiguous) >>>>>>>>>>>>>> >>>>>>>>>>>>>> JCTree: inconsistent layout of annotations; inconsistent >>>>>>>>>>>>>> use of >>>>>>>>>>>>>> @Deprecated and @Deprecated(forRemoval=true) >>>>>>>>>>>>>> >>>>>>>>>>>>>> (tests) >>>>>>>>>>>>>> Not reviewed in detail yet. >>>>>>>>>>>>>> New test descriptions should use "/*" for jtreg comment >>>>>>>>>>>>>> block; >>>>>>>>>>>>>> not >>>>>>>>>>>>>> "/**". These are not javadoc documentation comments. >>>>>>>>>>>>>> New test descriptions should have @summary >>>>>>>>>>>>>> Presumably, we will have to change the -old.out files if the >>>>>>>>>>>>>> preview >>>>>>>>>>>>>> feature becomes standard in JDK 13. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Overall, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The logic is nice, but the use of >>>>>>>>>>>>>> @Deprecated(forRemoval=true) >>>>>>>>>>>>>> and >>>>>>>>>>>>>> resulting @SuppressWarnings really suck. >>>>>>>>>>>>>> I don't think the current practice is serving us well. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Jon >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As JEP 325 is in the proposed to target state, I thought it >>>>>>>>>>>>>>> might >>>>>>>>>>>>>>> be a >>>>>>>>>>>>>>> good idea to start a review process for the code. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The code here strives to implement the current >>>>>>>>>>>>>>> specification >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> Switch Expressions: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The current webrev is here: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (includes a list of new errors.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> JBS: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> CSRs: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any feedback is welcome! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> ??? Jan >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>> >> From james.laskey at oracle.com Mon Aug 27 16:13:07 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 27 Aug 2018 13:13:07 -0300 Subject: RFR: JDK-8206981 - Compiler support for Raw String Literals Message-ID: <160C192A-04A7-4C54-80EF-FD3687487B06@oracle.com> Please review the following changeset to implement raw string literals in javac as per JEP 326. Thank you, ? Jim WEBREV: http://cr.openjdk.java.net/~jlaskey/8206981/webrev/index.html JEP: https://bugs.openjdk.java.net/browse/JDK-8196004 JBS: https://bugs.openjdk.java.net/browse/JDK-8206981 CSR: https://bugs.openjdk.java.net/browse/JDK-8198986 From jonathan.gibbons at oracle.com Mon Aug 27 17:39:12 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 27 Aug 2018 10:39:12 -0700 Subject: JEP 330 and MemoryClassLoader.getResourceAsStream In-Reply-To: References: <5B7DBC50.4050100@oracle.com> Message-ID: <7e97ce6c-4080-ae34-820c-04c088c084ea@oracle.com> This is now being tracked in JDK-8210009. https://bugs.openjdk.java.net/browse/JDK-8210009 -- Jon On 8/23/18 3:13 PM, seth lytle wrote: > thanks Jon (and sorry for the duplicate msg) > > > I would defer to ClassLoader experts as to whether it is reasonable to > provide getResourceAsStream but not getResource > > is the core-libs-dev list the best place to ask if this is reasonable ? > > > provide a URLStreamHandlerProvider > > yes, that seems like a bigger job > > > > On Wed, Aug 22, 2018 at 3:41 PM, Jonathan Gibbons > > wrote: > > Hi Seth, > > The provision of getResourceAsStream and getResource was > considered in the implementation of the Source File Launcher > feature ... and was dismissed at that time. > > * There are no "normal" resources in the (internal) > MemoryClassLoader; there are only the class files generated from > the source file. This implies that the provision of these methods > in MCL is just for the benefit for folk wanting access to the > bytyes for a .class file. (I'm not that that's bad; I'm just > saying that is so.) > > * Yes, we could reasonably easily provide getResourceAsStream, but > it seems weird to provide getResourceAsStream without also > providing an equivalent getResource, but URLs are not (currently) > supported for the content of the MemoryClassLoader.? Yes, > internally, some "fake" URLs are created to keep the API happy, > but these are not intended to be used by the end-user, and you'll > get an error if you try and open a stream from the URL.? I would > defer to ClassLoader experts as to whether it is reasonable to > provide getResourceAsStream but not getResource. > > It might be reasonable the jdk.compiler module to provide a > URLStreamHandlerProvider for these URLs; that would require some > consideration. > > -- Jon > > > > > On 08/21/2018 11:07 PM, seth lytle wrote: >> i'm working on adding JEP 330 single-file source invocation >> support to kilim (an ASM-based continuations library for java for >> which i'm the primary maintainer). we're prepping to promote my >> fork to the main site and i'd like to be able to support java 11 >> single-file source invocation as easily as classpath-based >> invocation, or at least confirm that the differences are intentional >> >> - i need access to the bytecode to weave it at runtime >> - MemoryClassLoader doesn't provide getResourceAsStream >> - it does cache the bytecode, so providing this appears to be >> easy to implement >> - currently, i access it with a javaagent that mimics >> MemoryClassLoader.map >> - https://github.com/nqzero/kilim/#java-versions >> >> - getResource is also missing, and again, much of the plumbing >> appears to be in place >> - i haven't tried manually building the "memory:///" style urls >> >> an example of my current invocation: >> ? cp=$(mvn -q dependency:build-classpath -Dmdep.outputFile=/dev/fd/1) >> ? $java11/bin/java -javaagent:${cp/:*} -cp $cp Xorshift.java >> >> what i'd like to be able to do: >> $java11/bin/java -cp $cp Xorshift.java >> >> >> i saw a previous thread that mentioned getResource in passing but >> no discussion of whether it was considered (un)desirable. is this >> feature planned ? are there problems with introducing it ? >> >> >> thanks for the great addition to java - using JEP 330 feels fun >> >> >> >> >> >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon Aug 27 17:47:08 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 27 Aug 2018 18:47:08 +0100 Subject: RFR: JDK-8206981 - Compiler support for Raw String Literals In-Reply-To: <160C192A-04A7-4C54-80EF-FD3687487B06@oracle.com> References: <160C192A-04A7-4C54-80EF-FD3687487B06@oracle.com> Message-ID: <2d2f7f19-2675-684d-38ff-7b37623a4239@oracle.com> Hi, looks very polished indeed, great work. One minor nit is that the API test could be improved by fuzzy testing all raw strings literals with varying number of start/end delimiters. Right now the test only checks unterminated literals where the number of ending delimiters is that of starting delimiters minus one. Not that I think this test will uncover a bug - looking at the tokenizer code it seems it should handle that just right - but just for piece of mind. Maurizio On 27/08/18 17:13, Jim Laskey wrote: > Please review the following changeset to implement raw string literals in javac as per JEP 326. > > Thank you, > > ? Jim > > WEBREV: http://cr.openjdk.java.net/~jlaskey/8206981/webrev/index.html > > > JEP: https://bugs.openjdk.java.net/browse/JDK-8196004 > JBS: https://bugs.openjdk.java.net/browse/JDK-8206981 > CSR: https://bugs.openjdk.java.net/browse/JDK-8198986 > From maurizio.cimadamore at oracle.com Mon Aug 27 17:48:54 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 27 Aug 2018 18:48:54 +0100 Subject: RFR: JDK-8206981 - Compiler support for Raw String Literals In-Reply-To: <2d2f7f19-2675-684d-38ff-7b37623a4239@oracle.com> References: <160C192A-04A7-4C54-80EF-FD3687487B06@oracle.com> <2d2f7f19-2675-684d-38ff-7b37623a4239@oracle.com> Message-ID: <543026e7-aa7b-2da8-62d0-26e837fd0a39@oracle.com> Ah - the @module tag in the RawStringLiteralLang test is probably unnecessary. Maurizio On 27/08/18 18:47, Maurizio Cimadamore wrote: > Hi, > looks very polished indeed, great work. > > One minor nit is that the API test could be improved by fuzzy testing > all raw strings literals with varying number of start/end delimiters. > Right now the test only checks unterminated literals where the number > of ending delimiters is that of starting delimiters minus one. Not > that I think this test will uncover a bug - looking at the tokenizer > code it seems it should handle that just right - but just for piece of > mind. > > Maurizio > > > On 27/08/18 17:13, Jim Laskey wrote: >> Please review the following changeset to implement raw string >> literals in javac as per JEP 326. >> >> Thank you, >> >> ? Jim >> >> WEBREV: http://cr.openjdk.java.net/~jlaskey/8206981/webrev/index.html >> >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8196004 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8206981 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8198986 >> > From alex.buckley at oracle.com Mon Aug 27 17:54:54 2018 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 27 Aug 2018 10:54:54 -0700 Subject: RFR: JDK-8206981 - Compiler support for Raw String Literals In-Reply-To: <160C192A-04A7-4C54-80EF-FD3687487B06@oracle.com> References: <160C192A-04A7-4C54-80EF-FD3687487B06@oracle.com> Message-ID: <5B843AEE.8030108@oracle.com> On 8/27/2018 9:13 AM, Jim Laskey wrote: > Please review the following changeset to implement raw string literals in javac as per JEP 326. ... > JEP: https://bugs.openjdk.java.net/browse/JDK-8196004 > JBS: https://bugs.openjdk.java.net/browse/JDK-8206981 > CSR: https://bugs.openjdk.java.net/browse/JDK-8198986 A minor correction: The last URL, https://bugs.openjdk.java.net/browse/JDK-8198986, is for the JLS changes themselves, not the CSR. The CSR, which accredits the javac changes, is https://bugs.openjdk.java.net/browse/JDK-8206982. Alex From jonathan.gibbons at oracle.com Mon Aug 27 22:52:48 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 27 Aug 2018 15:52:48 -0700 Subject: RFR: JDK-8208608: Update --module-source-path to allow explicit source paths for specific modules Message-ID: <5B8480C0.6090708@oracle.com> Please review a moderately simple update to the --module-source-path option supported directly by javac and thus indirectly by javadoc. The change is to allow a new form, similar to that used for the --patch-module option, which allows an explicit source path to be provided for any specific module, without having to use the existing pattern-based syntax. The CSR is in review. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8208608 CSR: https://bugs.openjdk.java.net/browse/JDK-8208609 Webrev: http://cr.openjdk.java.net/~jjg/8208608/webrev.00/ From jan.lahoda at oracle.com Tue Aug 28 12:41:19 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 28 Aug 2018 14:41:19 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <58e9e825-a027-f1fb-8b59-48bd16caffd8@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> <5B64652C.5020000@oracle.com> <5B64BA7A.2010406@oracle.com> <1d6b0189-89a0-7e41-4a04-967383e89400@oracle.com> <5B6C27E9.9050902@oracle.com> <5B6C2C95.5080609@oracle.com> <3d8d27b0-7bfc-2c26-17b4-53b8bf2abf20@oracle.com> <5B84056F.4090000@oracle.com> <58e9e825-a027-f1fb-8b59-48bd16caffd8@oracle.com> Message-ID: <5B8542EF.4040805@oracle.com> On 27.8.2018 16:32, Maurizio Cimadamore wrote: > Sensible fixes - generally looks good. > > The change to analyzeParens is subtle - that is, if you see something > like (x) -> ..., that logic would reasonably conclude that the > parenthesis corresponds to an implicit lambda decl - so parser would > attempt to go there, which at first seems sensible. But in reality, when > inside a 'case' you really want the compiler to process a (x) followed > by an arrow (->), where the former is the (parenthesized) constant > expression and the latter is the CASE arrow. > > But, one followup question is: what happens with this? > > case (x, y) -> 42 > > I believe your patch now classify this as a parenthesized expression, > which probably generates several downstream errors? An updated webrev, which improves the text of some of the relevant errors here: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.06/ Delta to the last revision: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.05.06/ For "case (a, b) -> {}", this produces (classifying (a, b) as parenthesized): --- SwitchArrowBrokenConstant.java:13: error: ')' expected case (a, b) -> {} ^ SwitchArrowBrokenConstant.java:13: error: : or -> expected case (a, b) -> {} ^ --- It would be nicer if the second error didn't occur, but not sure how to do that. It would be easy to change the classification in this case to lambda, the error would then be: --- SwitchArrowBrokenConstant.java:13: error: : or -> expected case (a, b) -> {} ^ --- (Only this single error.) But it seems it might suggest it is OK to continue from here with ':' or '->', while it is not OK. So I incline more to the variant which starts with "')' expected", even if there's a second error that's not very nice. What do you think? Thanks, Jan > > Maurizio > > On 27/08/18 15:06, Jan Lahoda wrote: >> Hello, >> >> Turned out there were some bugs in the last patch: >> -when parsing constant in rule cases ("case -> ..."), >> lambda expression parsing is disabled, but the flag that disables >> lambda expression parsing is cleared for more complicated expressions >> like "case a + a -> ...". The proposed patch tweaks the JavacParser to >> preserve the flag when parsing mode changes. The test >> (RuleParsingTest) intentionally tests also expressions that are not >> constants, to ensure error recovery can handle them. >> >> -when the expression in a value break is a lambda, it is not processed >> by LambdaToMethod properly. Fixed by a tweak to TreeTranslator to also >> translate value breaks >> >> A patch that fixes these problems, and also adds tests for variable >> scopes in switches with rule cases is here: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.05/ >> >> Delta webrev from previous version: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.04.05/ >> >> Any feedback is welcome! >> >> Thanks, >> Jan >> >> On 9.8.2018 14:53, Maurizio Cimadamore wrote: >>> Looks good. >>> >>> Maurizio >>> >>> >>> On 09/08/18 12:59, Jan Lahoda wrote: >>>> One more tiny change to tests to fix a failure on Windows (I apologize >>>> for not folding that into the previous update): >>>> webrev: >>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.04/ >>>> delta from previous (webrev.03): >>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.03.04/ >>>> >>>> Thanks, >>>> Jan >>>> >>>> On 9.8.2018 13:39, Jan Lahoda wrote: >>>>> On 3.8.2018 22:39, Maurizio Cimadamore wrote: >>>>>> Looks good - when I eyeballed compiler.properties earlier I missed >>>>>> this: >>>>>> >>>>>> "value break not supported in 'enhanced for' " >>>>>> >>>>>> I understand why you get 'enhanced for', not sure that adds value >>>>>> w.r.t. >>>>>> just 'for'. I don't have a strong opinion. >>>>> >>>>> Sounds reasonable, I've updated the compiler.properties, and added one >>>>> more test for SimpleTreeVisitor. >>>>> >>>>> An updated patch is here: >>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.03/ >>>>> >>>>> delta from the previous revision: >>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.02.03/ >>>>> >>>>> Diagnostics: >>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.03/diags.html >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>>>> >>>>>> Maurizio >>>>>> >>>>>> >>>>>> On 03/08/18 21:26, Jan Lahoda wrote: >>>>>>> On 3.8.2018 16:22, Jan Lahoda wrote: >>>>>>>> On 3.8.2018 15:47, Maurizio Cimadamore wrote: >>>>>>>>> I like the diagnostic changes, and the API change - I think it's >>>>>>>>> more >>>>>>>>> consistent now - thanks for taking a second look. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> I've forgot to include the generated examples for this update, so >>>>>>>> I've >>>>>>>> placed it here: >>>>>>>> file:///usr/local/home/lahvac/src/jdk/cr.openjdk.java.net/8192963/webrev.02/diags.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I apologize for a wrong link, the correct one is: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/diags.html >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Jan >>>>>>>> >>>>>>>>> >>>>>>>>> Thumbs up. >>>>>>>>> >>>>>>>>> Maurizio >>>>>>>>> >>>>>>>>> >>>>>>>>> On 03/08/18 14:35, Jan Lahoda wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Thanks for all the comments. An updated patch is here: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.02/ >>>>>>>>>> Changes against the previous revision: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.01.02/ >>>>>>>>>> >>>>>>>>>> Updated specdiff: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/api.diff.02/overview-summary.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Any feedback is welcome. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>>> On 1.8.2018 18:39, Maurizio Cimadamore wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 01/08/18 16:43, Jan Lahoda wrote: >>>>>>>>>>>> Hi Maurizio, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the comments - responses are inlined. >>>>>>>>>>>> >>>>>>>>>>>> On 1.8.2018 16:04, Maurizio Cimadamore wrote: >>>>>>>>>>>>> Hi Jan, >>>>>>>>>>>>> great work, some comments below. >>>>>>>>>>>>> >>>>>>>>>>>>> * Diagnostics. I see that some diagnostics seem to be >>>>>>>>>>>>> inconsistent >>>>>>>>>>>>> with >>>>>>>>>>>>> what we do for 'return' - e.g. javac diagnostics for 'return' >>>>>>>>>>>>> are >>>>>>>>>>>>> quite >>>>>>>>>>>>> succint: >>>>>>>>>>>>> >>>>>>>>>>>>> - "return outside method" >>>>>>>>>>>>> >>>>>>>>>>>>> - "missing return statement" >>>>>>>>>>>>> >>>>>>>>>>>>> - "unexpected return value" >>>>>>>>>>>>> >>>>>>>>>>>>> - "error: incompatible types: String cannot be converted to >>>>>>>>>>>>> int" >>>>>>>>>>>>> >>>>>>>>>>>>> The analogous conditions for break in switch expression seem >>>>>>>>>>>>> to be >>>>>>>>>>>>> more >>>>>>>>>>>>> verbose: >>>>>>>>>>>>> >>>>>>>>>>>>> - "expression break not immediately enclosed by a switch >>>>>>>>>>>>> expression" >>>>>>>>>>>> >>>>>>>>>>>> I think the closest error to "return outside method" is "value >>>>>>>>>>>> break >>>>>>>>>>>> outside of switch expression". The "expression break not >>>>>>>>>>>> immediately >>>>>>>>>>>> enclosed by a switch expression" is used when the break is >>>>>>>>>>>> inside >>>>>>>>>>>> another breakable statement inside the switch expression. I >>>>>>>>>>>> guess >>>>>>>>>>>> this >>>>>>>>>>>> should be rephrased at least to "value break not immediately >>>>>>>>>>>> enclosed >>>>>>>>>>>> by switch expression". >>>>>>>>>>>> >>>>>>>>>>> Fine, but do we need two distinct errors? Or do we need maybe >>>>>>>>>>> the >>>>>>>>>>> same >>>>>>>>>>> error and an extra detail string at the bottom for the 'you are >>>>>>>>>>> inside a >>>>>>>>>>> switch expr, but there's some other breaky context in between' >>>>>>>>>>> condition? >>>>>>>>>>>>> >>>>>>>>>>>>> - "break is missing a value to return from switch expression" >>>>>>>>>>>> >>>>>>>>>>>> How about >>>>>>>>>>>> "missing break value"? >>>>>>>>>>>> >>>>>>>>>>>> (the break is present, but the value is missing.) >>>>>>>>>>> I'm fine with that! >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - There's no equivalent for the third above - probably the >>>>>>>>>>>>> closest >>>>>>>>>>>>> condition would be to 'break expr' from a switch statement, in >>>>>>>>>>>>> which >>>>>>>>>>>>> case I bet you get a 'missing label' error - should we rectify >>>>>>>>>>>>> that >>>>>>>>>>>>> too? >>>>>>>>>>>> >>>>>>>>>>>> There are several conditions, and the error differ, consider: >>>>>>>>>>>> --- >>>>>>>>>>>> public class SwitchExpr { >>>>>>>>>>>> private void breakTest(int e) { >>>>>>>>>>>> break ; >>>>>>>>>>>> break x; >>>>>>>>>>>> break (e); >>>>>>>>>>>> while (true) { >>>>>>>>>>>> break x; >>>>>>>>>>>> break (e); >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> This gives: >>>>>>>>>>>> --- >>>>>>>>>>>> SwitchExpr.java:3: error: break outside switch or loop >>>>>>>>>>>> break ; >>>>>>>>>>>> ^ >>>>>>>>>>>> SwitchExpr.java:4: error: undefined label: x >>>>>>>>>>>> break x; >>>>>>>>>>>> ^ >>>>>>>>>>>> SwitchExpr.java:5: error: value break outside of switch >>>>>>>>>>>> expression >>>>>>>>>>>> break (e); >>>>>>>>>>>> ^ >>>>>>>>>>>> SwitchExpr.java:7: error: undefined label: x >>>>>>>>>>>> break x; >>>>>>>>>>>> ^ >>>>>>>>>>>> SwitchExpr.java:8: error: value break outside of switch >>>>>>>>>>>> expression >>>>>>>>>>>> break (e); >>>>>>>>>>>> ^ >>>>>>>>>>>> 5 errors >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> So when it is clear the break is a value break, a value break >>>>>>>>>>>> related >>>>>>>>>>>> diagnostic is reported, otherwise, the errors fall back to the >>>>>>>>>>>> existing diagnostics of cannot find labels. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - "incompatible types: bad type in switch expression" >>>>>>>>>>>>> ... >>>>>>>>>>>>> (A cannot be converted to B) >>>>>>>>>>>> >>>>>>>>>>>> I think this was modelled based on conditional expressions: >>>>>>>>>>>> SwitchExpr.java:10: error: incompatible types: bad type in >>>>>>>>>>>> conditional >>>>>>>>>>>> expression >>>>>>>>>>>> B b = e == 0 ? (A) null : (B) null; >>>>>>>>>>>> ^ >>>>>>>>>>>> A cannot be converted to B >>>>>>>>>>>> >>>>>>>>>>>> I'll look if this can be changed. >>>>>>>>>>> I see, I'm not a big fan of the conditional expression >>>>>>>>>>> nesting too >>>>>>>>>>> - I >>>>>>>>>>> think the important part is 'A != B' and it should be put front >>>>>>>>>>> and >>>>>>>>>>> center. That said, this is not a blocking issue, and I'm ok >>>>>>>>>>> with a >>>>>>>>>>> followup. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Not sure whether we should try to maintain the same style >>>>>>>>>>>>> across >>>>>>>>>>>>> break/return, but it seemed worth at least pointing out. >>>>>>>>>>>>> >>>>>>>>>>>>> Other diagnostic comments: >>>>>>>>>>>>> >>>>>>>>>>>>> - "error: j is ambiguously both a valid expression and a valid >>>>>>>>>>>>> label" - >>>>>>>>>>>>> this seems convoluted, I would personally rephrase as >>>>>>>>>>>>> something >>>>>>>>>>>>> like: >>>>>>>>>>>>> >>>>>>>>>>>>> ambiguous reference to 'j' >>>>>>>>>>>>> ... >>>>>>>>>>>>> ('j' is both a label and an expression) >>>>>>>>>>>> >>>>>>>>>>>> Will done. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - "break is jumping outside of the enclosing switch >>>>>>>>>>>>> expression" -> >>>>>>>>>>>>> "break outside of enclosing switch expression" >>>>>>>>>>>> >>>>>>>>>>>> Will do. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - "continue is jumping outside of the enclosing switch >>>>>>>>>>>>> expression" -> >>>>>>>>>>>>> "continue outside of enclosing switch expression" >>>>>>>>>>>> >>>>>>>>>>>> Will do. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> * Attr - The refactoring of switchExpr into switch + >>>>>>>>>>>>> handleSwitch is >>>>>>>>>>>>> very sweet - I like it! >>>>>>>>>>>>> >>>>>>>>>>>>> * Flow - a bit odd that we have to make up a new tree to call >>>>>>>>>>>>> recordExit >>>>>>>>>>>>> - but I see why you're doing it :-) >>>>>>>>>>>>> >>>>>>>>>>>>> * Lower - it would be nice to have a comment on >>>>>>>>>>>>> SwitchExpression >>>>>>>>>>>>> that >>>>>>>>>>>>> shows what the generated code shape looks like; I think we do >>>>>>>>>>>>> that >>>>>>>>>>>>> for >>>>>>>>>>>>> other non-trivial translations (e.g. for each) >>>>>>>>>>>> >>>>>>>>>>>> Will do. >>>>>>>>>>> Thanks >>>>>>>>>>> Maurizio >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Jan >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> * ExpSwitchNestingTest - I see that this test is not using the >>>>>>>>>>>>> newer >>>>>>>>>>>>> combo framework. Actually, I'm not even sure this one needs >>>>>>>>>>>>> any >>>>>>>>>>>>> templating logic at all, as it seems the test is doing its own >>>>>>>>>>>>> replacements. But I was going to note that this test is not >>>>>>>>>>>>> using the >>>>>>>>>>>>> shared context enhancements, which I guess it's still ok >>>>>>>>>>>>> given the >>>>>>>>>>>>> number of combinations checked is low. Maybe worth keeping an >>>>>>>>>>>>> eye on >>>>>>>>>>>>> this in the future, should we keep adding new cases to it. >>>>>>>>>>>>> >>>>>>>>>>>>> Maurizio >>>>>>>>>>>>> >>>>>>>>>>>>> On 01/08/18 07:28, Jan Lahoda wrote: >>>>>>>>>>>>>> Hi Jon, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for the comments! >>>>>>>>>>>>>> >>>>>>>>>>>>>> An updated webrev that reflects the comments is here: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> A delta webrev between this webrev and the webrev.00 is here: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.delta.00.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Does this look better? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jan >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 28.7.2018 01:12, Jonathan Gibbons wrote: >>>>>>>>>>>>>>> CaseTree.java:52: spelling, "lables" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> CaseTree.java:84: "return" should be "returns". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Lots of @Deprecated annotations without corresponding >>>>>>>>>>>>>>> @deprecated >>>>>>>>>>>>>>> javadoc tag. >>>>>>>>>>>>>>> Should the @apiNote really be @deprecated. I also think that >>>>>>>>>>>>>>> using >>>>>>>>>>>>>>> @Deprecated >>>>>>>>>>>>>>> like this is "a bit smelly", and had a discussion with >>>>>>>>>>>>>>> Stuart >>>>>>>>>>>>>>> "Dr >>>>>>>>>>>>>>> Deprecator" regarding >>>>>>>>>>>>>>> my concerns. If nothing else, assuming the feature is a >>>>>>>>>>>>>>> success, we >>>>>>>>>>>>>>> are >>>>>>>>>>>>>>> setting up >>>>>>>>>>>>>>> a precedent of marking an API as deprecated-for-removal, and >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>> next >>>>>>>>>>>>>>> release, simply removing the annotation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Attr.java:1482: ugly use of @SuppressWarnings. I understand >>>>>>>>>>>>>>> why >>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>> there, >>>>>>>>>>>>>>> but it exemplifies why @Deprecated on the declaration is >>>>>>>>>>>>>>> a bad >>>>>>>>>>>>>>> idea. >>>>>>>>>>>>>>> It'll be too easy to not remove these annotations in JDK 13. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Attr:1825: why XXX >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> LambdaToMethod: unnecessary new import, CaseKind >>>>>>>>>>>>>>> Flow: unnecessary new import, CaseKind >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> JavacParser: order of imports >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> messages: generally, I think the text of the messages >>>>>>>>>>>>>>> could be >>>>>>>>>>>>>>> improved >>>>>>>>>>>>>>> (related but not new) we should somehow identify language >>>>>>>>>>>>>>> keywords >>>>>>>>>>>>>>> from >>>>>>>>>>>>>>> English text (i.e. words like `break, `case`, `continue`, >>>>>>>>>>>>>>> `return`) >>>>>>>>>>>>>>> 204: saying the name is both a valid label and a valid >>>>>>>>>>>>>>> expression >>>>>>>>>>>>>>> hints >>>>>>>>>>>>>>> at the cause but not the error (i.e. the name is ambiguous) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> JCTree: inconsistent layout of annotations; inconsistent >>>>>>>>>>>>>>> use of >>>>>>>>>>>>>>> @Deprecated and @Deprecated(forRemoval=true) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (tests) >>>>>>>>>>>>>>> Not reviewed in detail yet. >>>>>>>>>>>>>>> New test descriptions should use "/*" for jtreg comment >>>>>>>>>>>>>>> block; >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>> "/**". These are not javadoc documentation comments. >>>>>>>>>>>>>>> New test descriptions should have @summary >>>>>>>>>>>>>>> Presumably, we will have to change the -old.out files if the >>>>>>>>>>>>>>> preview >>>>>>>>>>>>>>> feature becomes standard in JDK 13. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Overall, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The logic is nice, but the use of >>>>>>>>>>>>>>> @Deprecated(forRemoval=true) >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> resulting @SuppressWarnings really suck. >>>>>>>>>>>>>>> I don't think the current practice is serving us well. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- Jon >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 07/17/2018 11:00 AM, Jan Lahoda wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As JEP 325 is in the proposed to target state, I thought it >>>>>>>>>>>>>>>> might >>>>>>>>>>>>>>>> be a >>>>>>>>>>>>>>>> good idea to start a review process for the code. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The code here strives to implement the current >>>>>>>>>>>>>>>> specification >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> Switch Expressions: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~gbierman/switch-expressions.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The current webrev is here: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (includes a list of new errors.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> JBS: >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8192963 >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8206986 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> CSRs: >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207241 >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8207406 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Any feedback is welcome! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Jan >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>> >>> > From maurizio.cimadamore at oracle.com Tue Aug 28 13:05:57 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 28 Aug 2018 14:05:57 +0100 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B8542EF.4040805@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> <5B64652C.5020000@oracle.com> <5B64BA7A.2010406@oracle.com> <1d6b0189-89a0-7e41-4a04-967383e89400@oracle.com> <5B6C27E9.9050902@oracle.com> <5B6C2C95.5080609@oracle.com> <3d8d27b0-7bfc-2c26-17b4-53b8bf2abf20@oracle.com> <5B84056F.4090000@oracle.com> <58e9e825-a027-f1fb-8b59-48bd16caffd8@oracle.com> <5B8542EF.4040805@oracle.com> Message-ID: <8e37a8bc-3c5f-c5db-c42f-536f900cee5d@oracle.com> On 28/08/18 13:41, Jan Lahoda wrote: > It would be nicer if the second error didn't occur, but not sure how > to do that. It would be easy to change the classification in this case > to lambda, the error would then be: > --- > SwitchArrowBrokenConstant.java:13: error: : or -> expected > ??????????? case (a, b) -> {} > ???????????????????????????? ^ > --- > > (Only this single error.) But it seems it might suggest it is OK to > continue from here with ':' or '->', while it is not OK. So I incline > more to the variant which starts with "')' expected", even if there's > a second error that's not very nice. If classification is changed to lambda, then can't we add some check in the lambda parsing code so that if the 'lambda allowed' mode is not set, an error of the kind: 'lambda not expected here' is generated? Maurizio From jan.lahoda at oracle.com Tue Aug 28 13:50:15 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 28 Aug 2018 15:50:15 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <8e37a8bc-3c5f-c5db-c42f-536f900cee5d@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> <5B64652C.5020000@oracle.com> <5B64BA7A.2010406@oracle.com> <1d6b0189-89a0-7e41-4a04-967383e89400@oracle.com> <5B6C27E9.9050902@oracle.com> <5B6C2C95.5080609@oracle.com> <3d8d27b0-7bfc-2c26-17b4-53b8bf2abf20@oracle.com> <5B84056F.4090000@oracle.com> <58e9e825-a027-f1fb-8b59-48bd16caffd8@oracle.com> <5B8542EF.4040805@oracle.com> <8e37a8bc-3c5f-c5db-c42f-536f900cee5d@oracle.com> Message-ID: <5B855317.4000209@oracle.com> On 28.8.2018 15:05, Maurizio Cimadamore wrote: > > > On 28/08/18 13:41, Jan Lahoda wrote: >> It would be nicer if the second error didn't occur, but not sure how >> to do that. It would be easy to change the classification in this case >> to lambda, the error would then be: >> --- >> SwitchArrowBrokenConstant.java:13: error: : or -> expected >> case (a, b) -> {} >> ^ >> --- >> >> (Only this single error.) But it seems it might suggest it is OK to >> continue from here with ':' or '->', while it is not OK. So I incline >> more to the variant which starts with "')' expected", even if there's >> a second error that's not very nice. > If classification is changed to lambda, then can't we add some check in > the lambda parsing code so that if the 'lambda allowed' mode is not set, > an error of the kind: > > 'lambda not expected here' > > is generated? Yes, that'd be doable I think: http://cr.openjdk.java.net/~jlahoda/8192963/webrev.classify.as.lambda/ Which would produce: SwitchArrowBrokenConstant.java:13: error: lambda expression not expected here case (a, b) -> {} ^ SwitchArrowBrokenConstant.java:13: error: : or -> expected case (a, b) -> {} ^ But it is not clear if the user intended to write a lambda expression here, or if the intent was to write a "deconstruction pattern"? Thanks, Jan > > Maurizio From maurizio.cimadamore at oracle.com Tue Aug 28 14:10:04 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 28 Aug 2018 15:10:04 +0100 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <5B855317.4000209@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> <5B64652C.5020000@oracle.com> <5B64BA7A.2010406@oracle.com> <1d6b0189-89a0-7e41-4a04-967383e89400@oracle.com> <5B6C27E9.9050902@oracle.com> <5B6C2C95.5080609@oracle.com> <3d8d27b0-7bfc-2c26-17b4-53b8bf2abf20@oracle.com> <5B84056F.4090000@oracle.com> <58e9e825-a027-f1fb-8b59-48bd16caffd8@oracle.com> <5B8542EF.4040805@oracle.com> <8e37a8bc-3c5f-c5db-c42f-536f900cee5d@oracle.com> <5B855317.4000209@oracle.com> Message-ID: <2296d963-6d09-ad99-5ee9-d29f03d68fad@oracle.com> On 28/08/18 14:50, Jan Lahoda wrote: > On 28.8.2018 15:05, Maurizio Cimadamore wrote: >> >> >> On 28/08/18 13:41, Jan Lahoda wrote: >>> It would be nicer if the second error didn't occur, but not sure how >>> to do that. It would be easy to change the classification in this case >>> to lambda, the error would then be: >>> --- >>> SwitchArrowBrokenConstant.java:13: error: : or -> expected >>> ??????????? case (a, b) -> {} >>> ???????????????????????????? ^ >>> --- >>> >>> (Only this single error.) But it seems it might suggest it is OK to >>> continue from here with ':' or '->', while it is not OK. So I incline >>> more to the variant which starts with "')' expected", even if there's >>> a second error that's not very nice. >> If classification is changed to lambda, then can't we add some check in >> the lambda parsing code so that if the 'lambda allowed' mode is not set, >> an error of the kind: >> >> 'lambda not expected here' >> >> is generated? > > Yes, that'd be doable I think: > http://cr.openjdk.java.net/~jlahoda/8192963/webrev.classify.as.lambda/ > > Which would produce: > SwitchArrowBrokenConstant.java:13: error: lambda expression not > expected here > ??????????? case (a, b) -> {} > ??????????????????????? ^ > SwitchArrowBrokenConstant.java:13: error: : or -> expected > ??????????? case (a, b) -> {} > ???????????????????????????? ^ > > But it is not clear if the user intended to write a lambda expression > here, or if the intent was to write a "deconstruction pattern"? Well, in my view, the user happened to write a perfectly valid lambda expression where a constant expression was expected. So, if it were me, I'd drop the last error about '->' or ':' expected and just focus on the lambda popping up on an unexpected place. Maurizio > > Thanks, > ??? Jan > >> >> Maurizio From maurizio.cimadamore at oracle.com Tue Aug 28 14:37:46 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 28 Aug 2018 15:37:46 +0100 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: <2296d963-6d09-ad99-5ee9-d29f03d68fad@oracle.com> References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> <5B64652C.5020000@oracle.com> <5B64BA7A.2010406@oracle.com> <1d6b0189-89a0-7e41-4a04-967383e89400@oracle.com> <5B6C27E9.9050902@oracle.com> <5B6C2C95.5080609@oracle.com> <3d8d27b0-7bfc-2c26-17b4-53b8bf2abf20@oracle.com> <5B84056F.4090000@oracle.com> <58e9e825-a027-f1fb-8b59-48bd16caffd8@oracle.com> <5B8542EF.4040805@oracle.com> <8e37a8bc-3c5f-c5db-c42f-536f900cee5d@oracle.com> <5B855317.4000209@oracle.com> <2296d963-6d09-ad99-5ee9-d29f03d68fad@oracle.com> Message-ID: On 28/08/18 15:10, Maurizio Cimadamore wrote: > > > On 28/08/18 14:50, Jan Lahoda wrote: >> On 28.8.2018 15:05, Maurizio Cimadamore wrote: >>> >>> >>> On 28/08/18 13:41, Jan Lahoda wrote: >>>> It would be nicer if the second error didn't occur, but not sure how >>>> to do that. It would be easy to change the classification in this case >>>> to lambda, the error would then be: >>>> --- >>>> SwitchArrowBrokenConstant.java:13: error: : or -> expected >>>> ??????????? case (a, b) -> {} >>>> ???????????????????????????? ^ >>>> --- >>>> >>>> (Only this single error.) But it seems it might suggest it is OK to >>>> continue from here with ':' or '->', while it is not OK. So I incline >>>> more to the variant which starts with "')' expected", even if there's >>>> a second error that's not very nice. >>> If classification is changed to lambda, then can't we add some check in >>> the lambda parsing code so that if the 'lambda allowed' mode is not >>> set, >>> an error of the kind: >>> >>> 'lambda not expected here' >>> >>> is generated? >> >> Yes, that'd be doable I think: >> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.classify.as.lambda/ >> >> Which would produce: >> SwitchArrowBrokenConstant.java:13: error: lambda expression not >> expected here >> ??????????? case (a, b) -> {} >> ??????????????????????? ^ >> SwitchArrowBrokenConstant.java:13: error: : or -> expected >> ??????????? case (a, b) -> {} >> ???????????????????????????? ^ >> >> But it is not clear if the user intended to write a lambda expression >> here, or if the intent was to write a "deconstruction pattern"? > Well, in my view, the user happened to write a perfectly valid lambda > expression where a constant expression was expected. So, if it were > me, I'd drop the last error about '->' or ':' expected and just focus > on the lambda popping up on an unexpected place. In any case, just to be clear - your latest webrev is fine - I think we're discussing on very minor error recovery details and I see no need to hold back the code because of this. We can file followup issues for these kind of bugs, and re-evaluate as we gather more feedback? Maurizio > > Maurizio >> >> Thanks, >> ??? Jan >> >>> >>> Maurizio > From jan.lahoda at oracle.com Tue Aug 28 15:47:52 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 28 Aug 2018 17:47:52 +0200 Subject: RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview) In-Reply-To: References: <5B4E2ECA.5070805@oracle.com> <5B5BA6E2.9000208@oracle.com> <5B615310.2030702@oracle.com> <8b020c64-679b-80fa-25b7-00aaf2ba5523@oracle.com> <5B61D51B.3070905@oracle.com> <5B645A08.50601@oracle.com> <208cc7bb-5d21-f432-67e8-3c85a95b1aa8@oracle.com> <5B64652C.5020000@oracle.com> <5B64BA7A.2010406@oracle.com> <1d6b0189-89a0-7e41-4a04-967383e89400@oracle.com> <5B6C27E9.9050902@oracle.com> <5B6C2C95.5080609@oracle.com> <3d8d27b0-7bfc-2c26-17b4-53b8bf2abf20@oracle.com> <5B84056F.4090000@oracle.com> <58e9e825-a027-f1fb-8b59-48bd16caffd8@oracle.com> <5B8542EF.4040805@oracle.com> <8e37a8bc-3c5f-c5db-c42f-536f900cee5d@oracle.com> <5B855317.4000209@oracle.com> <2296d963-6d09-ad99-5ee9-d29f03d68fad@oracle.com> Message-ID: <5B856EA8.2030202@oracle.com> On 28.8.2018 16:37, Maurizio Cimadamore wrote: > > > On 28/08/18 15:10, Maurizio Cimadamore wrote: >> >> >> On 28/08/18 14:50, Jan Lahoda wrote: >>> On 28.8.2018 15:05, Maurizio Cimadamore wrote: >>>> >>>> >>>> On 28/08/18 13:41, Jan Lahoda wrote: >>>>> It would be nicer if the second error didn't occur, but not sure how >>>>> to do that. It would be easy to change the classification in this case >>>>> to lambda, the error would then be: >>>>> --- >>>>> SwitchArrowBrokenConstant.java:13: error: : or -> expected >>>>> case (a, b) -> {} >>>>> ^ >>>>> --- >>>>> >>>>> (Only this single error.) But it seems it might suggest it is OK to >>>>> continue from here with ':' or '->', while it is not OK. So I incline >>>>> more to the variant which starts with "')' expected", even if there's >>>>> a second error that's not very nice. >>>> If classification is changed to lambda, then can't we add some check in >>>> the lambda parsing code so that if the 'lambda allowed' mode is not >>>> set, >>>> an error of the kind: >>>> >>>> 'lambda not expected here' >>>> >>>> is generated? >>> >>> Yes, that'd be doable I think: >>> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.classify.as.lambda/ >>> >>> Which would produce: >>> SwitchArrowBrokenConstant.java:13: error: lambda expression not >>> expected here >>> case (a, b) -> {} >>> ^ >>> SwitchArrowBrokenConstant.java:13: error: : or -> expected >>> case (a, b) -> {} >>> ^ >>> >>> But it is not clear if the user intended to write a lambda expression >>> here, or if the intent was to write a "deconstruction pattern"? >> Well, in my view, the user happened to write a perfectly valid lambda >> expression where a constant expression was expected. So, if it were >> me, I'd drop the last error about '->' or ':' expected and just focus >> on the lambda popping up on an unexpected place. > In any case, just to be clear - your latest webrev is fine - I think > we're discussing on very minor error recovery details and I see no need > to hold back the code because of this. We can file followup issues for > these kind of bugs, and re-evaluate as we gather more feedback? Thanks, I'll file a follow-up bug. Jan > > Maurizio >> >> Maurizio >>> >>> Thanks, >>> Jan >>> >>>> >>>> Maurizio >> > From erik.joelsson at oracle.com Tue Aug 28 16:20:31 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 Aug 2018 09:20:31 -0700 Subject: RFR 8209064: Make intellij support more robust after changes for 2018.2 In-Reply-To: <9666fa9e-d38c-aa34-8ab3-2489a2defc58@oracle.com> References: <63022bb6-5a5e-8b34-b73f-a7f7a368f8f4@oracle.com> <698c5ed2-604a-2425-a867-5bfbfa897c3b@oracle.com> <9666fa9e-d38c-aa34-8ab3-2489a2defc58@oracle.com> Message-ID: Looks ok to me. /Erik On 2018-08-27 07:07, Maurizio Cimadamore wrote: > As I was about to push this, I realize there was a minor nit with the > way in which build.xml files found some classes inside the generated > .idea folder - that is, the path to this folder was defined in a > relative way from the location of the script file. > > A more robust way to get there is to setup an idea.dir ant variable > which is dynamically populated by the IDE with the known location of > the project IML file. > > The only files touched were the two project build.xml files, as well > as the idea ant.xml files. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8209064_v2 > > Maurizio > > > On 23/08/18 14:21, Maurizio Cimadamore wrote: >> >> >> On 21/08/18 10:31, Magnus Ihse Bursie wrote: >>> Hi Maurizio! >>> >>> Even if this only incidentally relates to the build, please always >>> include build-dev when making changes in the "make" directory. >> I will - thanks >>> >>> As far as I can understand, your changes looks good. One question: >>> the build.xml was previously stored as a "template", and copied to >>> the output directory. Now it's left in the source tree. I assume >>> that there was no actual transformations or changes made to the >>> template before? So that the scripts do not modify the source tree >>> version, that is. >> You are correct - the script is not meant to be modified; customized >> properties are injected by the runtime environment - such properties >> are defined in the ant.xml file and that is indeed a template file >> (so it can be customized). >> >> Thanks >> Maurizio >>> >>> /Magnus >>> >>> On 2018-08-07 13:21, Maurizio Cimadamore wrote: >>>> Hi, >>>> last week I submitted an 'emergency' patch to fix intellij project >>>> support after 2018.2 changes. The goal of these changes was to move >>>> the build.xml ant file out of the .idea folder, as the IDE no >>>> longer supported DOM indexing in such folders (as a result of >>>> https://youtrack.jetbrains.com/issue/IDEA-189915). As a workaround, >>>> I tweaked the scripts to copy build.xml in the build folder. >>>> >>>> Thinking more about this issue, there's a more robust fix possible, >>>> which doesn't involve moving files to the build folder (which could >>>> be potentially unreliable, depending on how people build the JDK). >>>> In fact, the best solution is to leave build.xml where it is, and >>>> fix the remaining configuration files to point at it. This allows >>>> to revert all changes in the scripts that set up the project >>>> configuration (bin/idea.sh for JDK, and make/langtools/build.xml >>>> for langtools). >>>> >>>> For the langtools project a bit more changes were necessary, given >>>> that in langtools we did not have a 'template' folder - and all >>>> intellij files were dumped onto the same path. So I had to move the >>>> configuration langtools files (all but build.xml) under a new >>>> template folder (located under make/langtools/intellij/make) and >>>> place build.xml outside it. Then tweak the build.xml script to work >>>> off this new template folder. These are all small conceptual >>>> changes, but the impact on the webrev is quite biggie (because of >>>> file renaming etc.). >>>> >>>> I also took the chance to fix some issues with the JDK project ANT >>>> configuration (see changes in make/idea/template/workspace.xml), as >>>> the last changes did not update the location of the ant file used >>>> here - as a result no ant target entries were showing up under the >>>> Build menu. >>>> >>>> Webrev here: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/8209064/ >>>> >>>> Cheers >>>> Maurizio >>>> >>> >> > From jan.lahoda at oracle.com Tue Aug 28 19:51:02 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 28 Aug 2018 21:51:02 +0200 Subject: RFR: JDK-8206981 - Compiler support for Raw String Literals In-Reply-To: <160C192A-04A7-4C54-80EF-FD3687487B06@oracle.com> References: <160C192A-04A7-4C54-80EF-FD3687487B06@oracle.com> Message-ID: <5B85A7A6.9030109@oracle.com> Hi Jim, Overall looks OK. A few comments: -when there's an attempt to open a raw string literal with \u0060, seems the error would be: illegal character: '\u0060 in raw string literal delimiter' where the "\u0060 in raw string literal delimiter" is hardcoded in the source. It would be better if this text would be localizable. -it would be nice if the following tests could be added (unless they already exist and I missed them): --test for '\r\n' and '\r' handling --test for the case where there is a longer backtick sequence inside the literal than is the length of the delimiter sequence (e.g. ` ``` `) --test where a (valid or invalid) raw string literal ends at the very end of the input sequence (not a valid source code, but still might be good to ensure the logic works) -/othervm in RawStringLiteralLangAPI is probably unnecessary? -does the feature work in jshell? Should I take a look? Jan On 27.8.2018 18:13, Jim Laskey wrote: > Please review the following changeset to implement raw string literals in javac as per JEP 326. > > Thank you, > > ? Jim > > WEBREV: http://cr.openjdk.java.net/~jlaskey/8206981/webrev/index.html > > > JEP: https://bugs.openjdk.java.net/browse/JDK-8196004 > JBS: https://bugs.openjdk.java.net/browse/JDK-8206981 > CSR: https://bugs.openjdk.java.net/browse/JDK-8198986 > From mandrikov at gmail.com Wed Aug 29 07:21:24 2018 From: mandrikov at gmail.com (Evgeny Mandrikov) Date: Wed, 29 Aug 2018 09:21:24 +0200 Subject: JDK-8160928: javac incorrectly copies over interior type annotations to bridge method Message-ID: Hi, After discussion with Rory O'Donnel [1] I'd like to propose patch to backport JDK-8160928 [2] to JDK 8. New test alone fails as should, and tests pass after fix. Regards, Evgeny [1] https://groups.google.com/d/msg/jacoco-dev/oau1ACzKFRI/NDYrdWkiEQAJ [2] https://bugs.openjdk.java.net/browse/JDK-8160928 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8160928-backport.patch Type: text/x-patch Size: 6583 bytes Desc: not available URL: From mandrikov at gmail.com Wed Aug 29 10:33:25 2018 From: mandrikov at gmail.com (Evgeny Mandrikov) Date: Wed, 29 Aug 2018 12:33:25 +0200 Subject: JDK-8160928: javac incorrectly copies over interior type annotations to bridge method In-Reply-To: References: Message-ID: Looks like there is a problem with the MIME type identification, so re-sending patch in txt. And for clarity - it is for JDK 8u, and was done on top of current tip of http://hg.openjdk.java.net/jdk8u/jdk8u/langtools On Wed, Aug 29, 2018 at 9:21 AM Evgeny Mandrikov wrote: > Hi, > > After discussion with Rory O'Donnel [1] I'd like to propose patch to > backport JDK-8160928 [2] to JDK 8. > New test alone fails as should, and tests pass after fix. > > > Regards, > Evgeny > > > [1] https://groups.google.com/d/msg/jacoco-dev/oau1ACzKFRI/NDYrdWkiEQAJ > [2] https://bugs.openjdk.java.net/browse/JDK-8160928 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # HG changeset patch # User Evgeny Mandrikov # Date 1535527073 -7200 # Wed Aug 29 09:17:53 2018 +0200 # Node ID 6dbec1ff0ffcc5a076c08855bb6c5071bab627ee # Parent 7031ed34a60400768d5136df03cbf8f05e6d9a6b 8160928: javac incorrectly copies over interior type annotations to bridge method diff -r 7031ed34a604 -r 6dbec1ff0ffc src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java --- a/src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java Tue Jul 24 09:52:12 2018 -0700 +++ b/src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java Wed Aug 29 09:17:53 2018 +0200 @@ -31,10 +31,13 @@ import com.sun.tools.javac.comp.Annotate; import com.sun.tools.javac.comp.AttrContext; +import com.sun.tools.javac.code.Attribute.TypeCompound; +import com.sun.tools.javac.code.Kinds; import com.sun.tools.javac.comp.Env; import com.sun.tools.javac.util.*; import com.sun.tools.javac.util.Assert; import com.sun.tools.javac.util.List; +import com.sun.tools.javac.util.ListBuffer; import com.sun.tools.javac.util.Log; import com.sun.tools.javac.util.Pair; import static com.sun.tools.javac.code.Kinds.PCK; @@ -152,9 +155,22 @@ throw new NullPointerException(); } setDeclarationAttributes(other.getDeclarationAttributes()); - setTypeAttributes(other.getTypeAttributes()); - setInitTypeAttributes(other.getInitTypeAttributes()); - setClassInitTypeAttributes(other.getClassInitTypeAttributes()); + if ((sym.flags() & Flags.BRIDGE) != 0) { + Assert.check(other.sym.kind == Kinds.MTH); + ListBuffer typeAttributes = new ListBuffer<>(); + for (TypeCompound tc : other.getTypeAttributes()) { + // Carry over only contractual type annotations: i.e nothing interior to method body. + if (!tc.position.type.isLocal()) + typeAttributes.append(tc); + } + setTypeAttributes(typeAttributes.toList()); + } else { + setTypeAttributes(other.getTypeAttributes()); + } + if (sym.kind == Kinds.TYP) { + setInitTypeAttributes(other.getInitTypeAttributes()); + setClassInitTypeAttributes(other.getClassInitTypeAttributes()); + } } public void setDeclarationAttributesWithCompletion(final Annotate.AnnotateRepeatedContext ctx) { diff -r 7031ed34a604 -r 6dbec1ff0ffc test/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java Wed Aug 29 09:17:53 2018 +0200 @@ -0,0 +1,102 @@ +/* + * Copyright (c) 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 8160928 + * @summary javac incorrectly copies over interior type annotations to bridge method + * @run compile -g BridgeShouldHaveNoInteriorAnnotationsTest.java + * @run main BridgeShouldHaveNoInteriorAnnotationsTest + */ + +import java.lang.annotation.ElementType; +import java.lang.annotation.Target; +import java.io.*; + +class Pair_8160928 { +} + +public class BridgeShouldHaveNoInteriorAnnotationsTest implements java.util.Iterator> { + + @Override + public boolean hasNext() { + throw new RuntimeException(); + } + + @Override + public Pair_8160928<@NonNull Object, Object> next() { + Comparable<@NonNull Object> cble1 = (Comparable<@NonNull Object>) null; + return null; + } + + @Override + public void remove() { + throw new RuntimeException(); + } + + @Target(ElementType.TYPE_USE) + public @interface NonNull { + } + + static class OutputExpectedOnceHolder { + public String[] outputs = { + "0: #63(): CAST, offset=0, type_index=0, location=[TYPE_ARGUMENT(0)]", + "1: #63(): LOCAL_VARIABLE, {start_pc=5, length=2, index=1}, location=[TYPE_ARGUMENT(0)]", + }; + } + + static class OutputExpectedTwiceHolder { + public String[] outputs = { + "0: #63(): METHOD_RETURN, location=[TYPE_ARGUMENT(0)]", + }; + } + + public static void main(String[] args) throws Exception { + File testClasses = new File(System.getProperty("test.classes")); + File testClass = new File(testClasses, "BridgeShouldHaveNoInteriorAnnotationsTest.class"); + + StringWriter sw = new StringWriter(); + PrintWriter pw = new PrintWriter(sw); + int rc = com.sun.tools.javap.Main.run(new String[]{"-v", "-p", testClass.getPath()}, pw); + pw.close(); + if (rc != 0) { + throw new Error("javap failed unexpectedly"); + } + String javapOut = sw.toString(); + + OutputExpectedOnceHolder holder = new OutputExpectedOnceHolder(); + for (String s : holder.outputs) { + String newOutput = javapOut.replace(s, ""); + if (((javapOut.length() - newOutput.length()) / s.length()) != 1) + throw new AssertionError("Interior annotations carried over to bridge ?"); + } + + OutputExpectedTwiceHolder holder2 = new OutputExpectedTwiceHolder(); + for (String s : holder2.outputs) { + String newOutput = javapOut.replace(s, ""); + if (((javapOut.length() - newOutput.length()) / s.length()) != 2) + throw new AssertionError("Exterior annotations not properly carried over to bridge"); + } + } + +} From james.laskey at oracle.com Wed Aug 29 16:43:00 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 29 Aug 2018 13:43:00 -0300 Subject: RFR: JDK-8206981 - Compiler support for Raw String Literals In-Reply-To: <5B85A7A6.9030109@oracle.com> References: <160C192A-04A7-4C54-80EF-FD3687487B06@oracle.com> <5B85A7A6.9030109@oracle.com> Message-ID: <5AF5F7F7-AC15-47D1-9047-BC1F7E14EC24@oracle.com> Thank you Jan. Updated webrev in http://cr.openjdk.java.net/~jlaskey/8206981/webrev-01/index.html . Cheers, ? Jim > On Aug 28, 2018, at 4:51 PM, Jan Lahoda wrote: > > Hi Jim, > > Overall looks OK. A few comments: > -when there's an attempt to open a raw string literal with \u0060, seems the error would be: > > illegal character: '\u0060 in raw string literal delimiter' > > where the "\u0060 in raw string literal delimiter" is hardcoded in the source. It would be better if this text would be localizable. Updated > > -it would be nice if the following tests could be added (unless they already exist and I missed them): > --test for '\r\n' and '\r? handling Added > --test for the case where there is a longer backtick sequence inside the literal than is the length of the delimiter sequence (e.g. ` ``` `) Already there. j varies the inside sequence independently of i (open) and k (close). > --test where a (valid or invalid) raw string literal ends at the very end of the input sequence (not a valid source code, but still might be good to ensure the logic works) Added > > -/othervm in RawStringLiteralLangAPI is probably unnecessary? Hangs without it. > > -does the feature work in jshell? Should I take a look? > > Jan > > > On 27.8.2018 18:13, Jim Laskey wrote: >> Please review the following changeset to implement raw string literals in javac as per JEP 326. >> >> Thank you, >> >> ? Jim >> >> WEBREV: http://cr.openjdk.java.net/~jlaskey/8206981/webrev/index.html >> >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8196004 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8206981 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8198986 >> From jan.lahoda at oracle.com Thu Aug 30 10:33:42 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 30 Aug 2018 12:33:42 +0200 Subject: RFR: JDK-8208608: Update --module-source-path to allow explicit source paths for specific modules In-Reply-To: <5B8480C0.6090708@oracle.com> References: <5B8480C0.6090708@oracle.com> Message-ID: <5B87C806.5080509@oracle.com> Looks good to me. Jan On 28.8.2018 00:52, Jonathan Gibbons wrote: > Please review a moderately simple update to the --module-source-path option > supported directly by javac and thus indirectly by javadoc. > > The change is to allow a new form, similar to that used for the > --patch-module > option, which allows an explicit source path to be provided for any > specific module, > without having to use the existing pattern-based syntax. > > The CSR is in review. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8208608 > CSR: https://bugs.openjdk.java.net/browse/JDK-8208609 > Webrev: http://cr.openjdk.java.net/~jjg/8208608/webrev.00/ > > From vicente.romero at oracle.com Thu Aug 30 13:36:51 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 30 Aug 2018 09:36:51 -0400 Subject: JDK-8160928: javac incorrectly copies over interior type annotations to bridge method In-Reply-To: References: Message-ID: why not using ToolBox in the test? We introduced it with the idea of using it for these cases Thanks, Vicente On 08/29/2018 06:33 AM, Evgeny Mandrikov wrote: > # HG changeset patch > # User Evgeny Mandrikov > # Date 1535527073 -7200 > # Wed Aug 29 09:17:53 2018 +0200 > # Node ID 6dbec1ff0ffcc5a076c08855bb6c5071bab627ee > # Parent 7031ed34a60400768d5136df03cbf8f05e6d9a6b > 8160928: javac incorrectly copies over interior type annotations to bridge method > > diff -r 7031ed34a604 -r 6dbec1ff0ffc src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java > --- a/src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java Tue Jul 24 09:52:12 2018 -0700 > +++ b/src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java Wed Aug 29 09:17:53 2018 +0200 > @@ -31,10 +31,13 @@ > > import com.sun.tools.javac.comp.Annotate; > import com.sun.tools.javac.comp.AttrContext; > +import com.sun.tools.javac.code.Attribute.TypeCompound; > +import com.sun.tools.javac.code.Kinds; > import com.sun.tools.javac.comp.Env; > import com.sun.tools.javac.util.*; > import com.sun.tools.javac.util.Assert; > import com.sun.tools.javac.util.List; > +import com.sun.tools.javac.util.ListBuffer; > import com.sun.tools.javac.util.Log; > import com.sun.tools.javac.util.Pair; > import static com.sun.tools.javac.code.Kinds.PCK; > @@ -152,9 +155,22 @@ > throw new NullPointerException(); > } > setDeclarationAttributes(other.getDeclarationAttributes()); > - setTypeAttributes(other.getTypeAttributes()); > - setInitTypeAttributes(other.getInitTypeAttributes()); > - setClassInitTypeAttributes(other.getClassInitTypeAttributes()); > + if ((sym.flags() & Flags.BRIDGE) != 0) { > + Assert.check(other.sym.kind == Kinds.MTH); > + ListBuffer typeAttributes = new ListBuffer<>(); > + for (TypeCompound tc : other.getTypeAttributes()) { > + // Carry over only contractual type annotations: i.e nothing interior to method body. > + if (!tc.position.type.isLocal()) > + typeAttributes.append(tc); > + } > + setTypeAttributes(typeAttributes.toList()); > + } else { > + setTypeAttributes(other.getTypeAttributes()); > + } > + if (sym.kind == Kinds.TYP) { > + setInitTypeAttributes(other.getInitTypeAttributes()); > + setClassInitTypeAttributes(other.getClassInitTypeAttributes()); > + } > } > > public void setDeclarationAttributesWithCompletion(final Annotate.AnnotateRepeatedContext ctx) { > diff -r 7031ed34a604 -r 6dbec1ff0ffc test/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java Wed Aug 29 09:17:53 2018 +0200 > @@ -0,0 +1,102 @@ > +/* > + * Copyright (c) 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 visitwww.oracle.com if you need additional information or have any > + * questions. > + */ > + > +/* > + * @test > + * @bug 8160928 > + * @summary javac incorrectly copies over interior type annotations to bridge method > + * @run compile -g BridgeShouldHaveNoInteriorAnnotationsTest.java > + * @run main BridgeShouldHaveNoInteriorAnnotationsTest > + */ > + > +import java.lang.annotation.ElementType; > +import java.lang.annotation.Target; > +import java.io.*; > + > +class Pair_8160928 { > +} > + > +public class BridgeShouldHaveNoInteriorAnnotationsTest implements java.util.Iterator> { > + > + @Override > + public boolean hasNext() { > + throw new RuntimeException(); > + } > + > + @Override > + public Pair_8160928<@NonNull Object, Object> next() { > + Comparable<@NonNull Object> cble1 = (Comparable<@NonNull Object>) null; > + return null; > + } > + > + @Override > + public void remove() { > + throw new RuntimeException(); > + } > + > + @Target(ElementType.TYPE_USE) > + public @interface NonNull { > + } > + > + static class OutputExpectedOnceHolder { > + public String[] outputs = { > + "0: #63(): CAST, offset=0, type_index=0, location=[TYPE_ARGUMENT(0)]", > + "1: #63(): LOCAL_VARIABLE, {start_pc=5, length=2, index=1}, location=[TYPE_ARGUMENT(0)]", > + }; > + } > + > + static class OutputExpectedTwiceHolder { > + public String[] outputs = { > + "0: #63(): METHOD_RETURN, location=[TYPE_ARGUMENT(0)]", > + }; > + } > + > + public static void main(String[] args) throws Exception { > + File testClasses = new File(System.getProperty("test.classes")); > + File testClass = new File(testClasses, "BridgeShouldHaveNoInteriorAnnotationsTest.class"); > + > + StringWriter sw = new StringWriter(); > + PrintWriter pw = new PrintWriter(sw); > + int rc = com.sun.tools.javap.Main.run(new String[]{"-v", "-p", testClass.getPath()}, pw); > + pw.close(); > + if (rc != 0) { > + throw new Error("javap failed unexpectedly"); > + } > + String javapOut = sw.toString(); > + > + OutputExpectedOnceHolder holder = new OutputExpectedOnceHolder(); > + for (String s : holder.outputs) { > + String newOutput = javapOut.replace(s, ""); > + if (((javapOut.length() - newOutput.length()) / s.length()) != 1) > + throw new AssertionError("Interior annotations carried over to bridge ?"); > + } > + > + OutputExpectedTwiceHolder holder2 = new OutputExpectedTwiceHolder(); > + for (String s : holder2.outputs) { > + String newOutput = javapOut.replace(s, ""); > + if (((javapOut.length() - newOutput.length()) / s.length()) != 2) > + throw new AssertionError("Exterior annotations not properly carried over to bridge"); > + } > + } > + > +} -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Thu Aug 30 13:47:21 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 30 Aug 2018 14:47:21 +0100 Subject: JDK-8160928: javac incorrectly copies over interior type annotations to bridge method In-Reply-To: References: Message-ID: Hi Vicente, Is Toolbox available in 8u-dev ? I assume that is why the workaround has been put in place? Maurizio On 30/08/18 14:36, Vicente Romero wrote: > why not using ToolBox in the test? We introduced it with the idea of > using it for these cases > > Thanks, > Vicente > > On 08/29/2018 06:33 AM, Evgeny Mandrikov wrote: >> # HG changeset patch >> # User Evgeny Mandrikov >> # Date 1535527073 -7200 >> # Wed Aug 29 09:17:53 2018 +0200 >> # Node ID 6dbec1ff0ffcc5a076c08855bb6c5071bab627ee >> # Parent 7031ed34a60400768d5136df03cbf8f05e6d9a6b >> 8160928: javac incorrectly copies over interior type annotations to bridge method >> >> diff -r 7031ed34a604 -r 6dbec1ff0ffc src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java >> --- a/src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java Tue Jul 24 09:52:12 2018 -0700 >> +++ b/src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java Wed Aug 29 09:17:53 2018 +0200 >> @@ -31,10 +31,13 @@ >> >> import com.sun.tools.javac.comp.Annotate; >> import com.sun.tools.javac.comp.AttrContext; >> +import com.sun.tools.javac.code.Attribute.TypeCompound; >> +import com.sun.tools.javac.code.Kinds; >> import com.sun.tools.javac.comp.Env; >> import com.sun.tools.javac.util.*; >> import com.sun.tools.javac.util.Assert; >> import com.sun.tools.javac.util.List; >> +import com.sun.tools.javac.util.ListBuffer; >> import com.sun.tools.javac.util.Log; >> import com.sun.tools.javac.util.Pair; >> import static com.sun.tools.javac.code.Kinds.PCK; >> @@ -152,9 +155,22 @@ >> throw new NullPointerException(); >> } >> setDeclarationAttributes(other.getDeclarationAttributes()); >> - setTypeAttributes(other.getTypeAttributes()); >> - setInitTypeAttributes(other.getInitTypeAttributes()); >> - setClassInitTypeAttributes(other.getClassInitTypeAttributes()); >> + if ((sym.flags() & Flags.BRIDGE) != 0) { >> + Assert.check(other.sym.kind == Kinds.MTH); >> + ListBuffer typeAttributes = new ListBuffer<>(); >> + for (TypeCompound tc : other.getTypeAttributes()) { >> + // Carry over only contractual type annotations: i.e nothing interior to method body. >> + if (!tc.position.type.isLocal()) >> + typeAttributes.append(tc); >> + } >> + setTypeAttributes(typeAttributes.toList()); >> + } else { >> + setTypeAttributes(other.getTypeAttributes()); >> + } >> + if (sym.kind == Kinds.TYP) { >> + setInitTypeAttributes(other.getInitTypeAttributes()); >> + setClassInitTypeAttributes(other.getClassInitTypeAttributes()); >> + } >> } >> >> public void setDeclarationAttributesWithCompletion(final Annotate.AnnotateRepeatedContext ctx) { >> diff -r 7031ed34a604 -r 6dbec1ff0ffc test/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> +++ b/test/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java Wed Aug 29 09:17:53 2018 +0200 >> @@ -0,0 +1,102 @@ >> +/* >> + * Copyright (c) 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 visitwww.oracle.com if you need additional information or have any >> + * questions. >> + */ >> + >> +/* >> + * @test >> + * @bug 8160928 >> + * @summary javac incorrectly copies over interior type annotations to bridge method >> + * @run compile -g BridgeShouldHaveNoInteriorAnnotationsTest.java >> + * @run main BridgeShouldHaveNoInteriorAnnotationsTest >> + */ >> + >> +import java.lang.annotation.ElementType; >> +import java.lang.annotation.Target; >> +import java.io.*; >> + >> +class Pair_8160928 { >> +} >> + >> +public class BridgeShouldHaveNoInteriorAnnotationsTest implements java.util.Iterator> { >> + >> + @Override >> + public boolean hasNext() { >> + throw new RuntimeException(); >> + } >> + >> + @Override >> + public Pair_8160928<@NonNull Object, Object> next() { >> + Comparable<@NonNull Object> cble1 = (Comparable<@NonNull Object>) null; >> + return null; >> + } >> + >> + @Override >> + public void remove() { >> + throw new RuntimeException(); >> + } >> + >> + @Target(ElementType.TYPE_USE) >> + public @interface NonNull { >> + } >> + >> + static class OutputExpectedOnceHolder { >> + public String[] outputs = { >> + "0: #63(): CAST, offset=0, type_index=0, location=[TYPE_ARGUMENT(0)]", >> + "1: #63(): LOCAL_VARIABLE, {start_pc=5, length=2, index=1}, location=[TYPE_ARGUMENT(0)]", >> + }; >> + } >> + >> + static class OutputExpectedTwiceHolder { >> + public String[] outputs = { >> + "0: #63(): METHOD_RETURN, location=[TYPE_ARGUMENT(0)]", >> + }; >> + } >> + >> + public static void main(String[] args) throws Exception { >> + File testClasses = new File(System.getProperty("test.classes")); >> + File testClass = new File(testClasses, "BridgeShouldHaveNoInteriorAnnotationsTest.class"); >> + >> + StringWriter sw = new StringWriter(); >> + PrintWriter pw = new PrintWriter(sw); >> + int rc = com.sun.tools.javap.Main.run(new String[]{"-v", "-p", testClass.getPath()}, pw); >> + pw.close(); >> + if (rc != 0) { >> + throw new Error("javap failed unexpectedly"); >> + } >> + String javapOut = sw.toString(); >> + >> + OutputExpectedOnceHolder holder = new OutputExpectedOnceHolder(); >> + for (String s : holder.outputs) { >> + String newOutput = javapOut.replace(s, ""); >> + if (((javapOut.length() - newOutput.length()) / s.length()) != 1) >> + throw new AssertionError("Interior annotations carried over to bridge ?"); >> + } >> + >> + OutputExpectedTwiceHolder holder2 = new OutputExpectedTwiceHolder(); >> + for (String s : holder2.outputs) { >> + String newOutput = javapOut.replace(s, ""); >> + if (((javapOut.length() - newOutput.length()) / s.length()) != 2) >> + throw new AssertionError("Exterior annotations not properly carried over to bridge"); >> + } >> + } >> + >> +} > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandrikov at gmail.com Thu Aug 30 13:58:53 2018 From: mandrikov at gmail.com (Evgeny Mandrikov) Date: Thu, 30 Aug 2018 15:58:53 +0200 Subject: JDK-8160928: javac incorrectly copies over interior type annotations to bridge method In-Reply-To: References: Message-ID: Actually it exists in 8 - http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/file/7031ed34a604/test/tools/javac/lib/ToolBox.java Unfortunately I initially missed this, because of difference in location/package compared to 9. Thank you, Vicente, for pointing this out. Will send updated patch shortly. On Thu, Aug 30, 2018 at 3:47 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi Vicente, > Is Toolbox available in 8u-dev ? I assume that is why the workaround has > been put in place? > > Maurizio > > On 30/08/18 14:36, Vicente Romero wrote: > > why not using ToolBox in the test? We introduced it with the idea of using > it for these cases > > Thanks, > Vicente > > On 08/29/2018 06:33 AM, Evgeny Mandrikov wrote: > > # HG changeset patch > # User Evgeny Mandrikov > # Date 1535527073 -7200 > # Wed Aug 29 09:17:53 2018 +0200 > # Node ID 6dbec1ff0ffcc5a076c08855bb6c5071bab627ee > # Parent 7031ed34a60400768d5136df03cbf8f05e6d9a6b > 8160928: javac incorrectly copies over interior type annotations to bridge method > > diff -r 7031ed34a604 -r 6dbec1ff0ffc src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java > --- a/src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java Tue Jul 24 09:52:12 2018 -0700 > +++ b/src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java Wed Aug 29 09:17:53 2018 +0200 > @@ -31,10 +31,13 @@ > > import com.sun.tools.javac.comp.Annotate; > import com.sun.tools.javac.comp.AttrContext; > +import com.sun.tools.javac.code.Attribute.TypeCompound; > +import com.sun.tools.javac.code.Kinds; > import com.sun.tools.javac.comp.Env; > import com.sun.tools.javac.util.*; > import com.sun.tools.javac.util.Assert; > import com.sun.tools.javac.util.List; > +import com.sun.tools.javac.util.ListBuffer; > import com.sun.tools.javac.util.Log; > import com.sun.tools.javac.util.Pair; > import static com.sun.tools.javac.code.Kinds.PCK; > @@ -152,9 +155,22 @@ > throw new NullPointerException(); > } > setDeclarationAttributes(other.getDeclarationAttributes()); > - setTypeAttributes(other.getTypeAttributes()); > - setInitTypeAttributes(other.getInitTypeAttributes()); > - setClassInitTypeAttributes(other.getClassInitTypeAttributes()); > + if ((sym.flags() & Flags.BRIDGE) != 0) { > + Assert.check(other.sym.kind == Kinds.MTH); > + ListBuffer typeAttributes = new ListBuffer<>(); > + for (TypeCompound tc : other.getTypeAttributes()) { > + // Carry over only contractual type annotations: i.e nothing interior to method body. > + if (!tc.position.type.isLocal()) > + typeAttributes.append(tc); > + } > + setTypeAttributes(typeAttributes.toList()); > + } else { > + setTypeAttributes(other.getTypeAttributes()); > + } > + if (sym.kind == Kinds.TYP) { > + setInitTypeAttributes(other.getInitTypeAttributes()); > + setClassInitTypeAttributes(other.getClassInitTypeAttributes()); > + } > } > > public void setDeclarationAttributesWithCompletion(final Annotate.AnnotateRepeatedContext ctx) { > diff -r 7031ed34a604 -r 6dbec1ff0ffc test/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/test/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java Wed Aug 29 09:17:53 2018 +0200 > @@ -0,0 +1,102 @@ > +/* > + * Copyright (c) 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 8160928 > + * @summary javac incorrectly copies over interior type annotations to bridge method > + * @run compile -g BridgeShouldHaveNoInteriorAnnotationsTest.java > + * @run main BridgeShouldHaveNoInteriorAnnotationsTest > + */ > + > +import java.lang.annotation.ElementType; > +import java.lang.annotation.Target; > +import java.io.*; > + > +class Pair_8160928 { > +} > + > +public class BridgeShouldHaveNoInteriorAnnotationsTest implements java.util.Iterator> { > + > + @Override > + public boolean hasNext() { > + throw new RuntimeException(); > + } > + > + @Override > + public Pair_8160928<@NonNull Object, Object> next() { > + Comparable<@NonNull Object> cble1 = (Comparable<@NonNull Object>) null; > + return null; > + } > + > + @Override > + public void remove() { > + throw new RuntimeException(); > + } > + > + @Target(ElementType.TYPE_USE) > + public @interface NonNull { > + } > + > + static class OutputExpectedOnceHolder { > + public String[] outputs = { > + "0: #63(): CAST, offset=0, type_index=0, location=[TYPE_ARGUMENT(0)]", > + "1: #63(): LOCAL_VARIABLE, {start_pc=5, length=2, index=1}, location=[TYPE_ARGUMENT(0)]", > + }; > + } > + > + static class OutputExpectedTwiceHolder { > + public String[] outputs = { > + "0: #63(): METHOD_RETURN, location=[TYPE_ARGUMENT(0)]", > + }; > + } > + > + public static void main(String[] args) throws Exception { > + File testClasses = new File(System.getProperty("test.classes")); > + File testClass = new File(testClasses, "BridgeShouldHaveNoInteriorAnnotationsTest.class"); > + > + StringWriter sw = new StringWriter(); > + PrintWriter pw = new PrintWriter(sw); > + int rc = com.sun.tools.javap.Main.run(new String[]{"-v", "-p", testClass.getPath()}, pw); > + pw.close(); > + if (rc != 0) { > + throw new Error("javap failed unexpectedly"); > + } > + String javapOut = sw.toString(); > + > + OutputExpectedOnceHolder holder = new OutputExpectedOnceHolder(); > + for (String s : holder.outputs) { > + String newOutput = javapOut.replace(s, ""); > + if (((javapOut.length() - newOutput.length()) / s.length()) != 1) > + throw new AssertionError("Interior annotations carried over to bridge ?"); > + } > + > + OutputExpectedTwiceHolder holder2 = new OutputExpectedTwiceHolder(); > + for (String s : holder2.outputs) { > + String newOutput = javapOut.replace(s, ""); > + if (((javapOut.length() - newOutput.length()) / s.length()) != 2) > + throw new AssertionError("Exterior annotations not properly carried over to bridge"); > + } > + } > + > +} > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandrikov at gmail.com Thu Aug 30 14:16:15 2018 From: mandrikov at gmail.com (Evgeny Mandrikov) Date: Thu, 30 Aug 2018 16:16:15 +0200 Subject: JDK-8160928: javac incorrectly copies over interior type annotations to bridge method In-Reply-To: References: Message-ID: Please see updated patch in attachment. Now it is even less different from original fix. Tests pass as before. Regards, Evgeny On Thu, Aug 30, 2018 at 3:58 PM Evgeny Mandrikov wrote: > Actually it exists in 8 - > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/file/7031ed34a604/test/tools/javac/lib/ToolBox.java > Unfortunately I initially missed this, because of difference in > location/package compared to 9. > Thank you, Vicente, for pointing this out. Will send updated patch shortly. > > On Thu, Aug 30, 2018 at 3:47 PM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> Hi Vicente, >> Is Toolbox available in 8u-dev ? I assume that is why the workaround has >> been put in place? >> >> Maurizio >> >> On 30/08/18 14:36, Vicente Romero wrote: >> >> why not using ToolBox in the test? We introduced it with the idea of >> using it for these cases >> >> Thanks, >> Vicente >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # HG changeset patch # User Evgeny Mandrikov # Date 1535499247 -7200 # Wed Aug 29 01:34:07 2018 +0200 # Node ID 5dce2796a9c54e4a692a3f38af1b01cd16910d6c # Parent 7031ed34a60400768d5136df03cbf8f05e6d9a6b 8160928: javac incorrectly copies over interior type annotations to bridge method diff -r 7031ed34a604 -r 5dce2796a9c5 src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java --- a/src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java Tue Jul 24 09:52:12 2018 -0700 +++ b/src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java Wed Aug 29 01:34:07 2018 +0200 @@ -31,10 +31,13 @@ import com.sun.tools.javac.comp.Annotate; import com.sun.tools.javac.comp.AttrContext; +import com.sun.tools.javac.code.Attribute.TypeCompound; +import com.sun.tools.javac.code.Kinds; import com.sun.tools.javac.comp.Env; import com.sun.tools.javac.util.*; import com.sun.tools.javac.util.Assert; import com.sun.tools.javac.util.List; +import com.sun.tools.javac.util.ListBuffer; import com.sun.tools.javac.util.Log; import com.sun.tools.javac.util.Pair; import static com.sun.tools.javac.code.Kinds.PCK; @@ -152,9 +155,22 @@ throw new NullPointerException(); } setDeclarationAttributes(other.getDeclarationAttributes()); - setTypeAttributes(other.getTypeAttributes()); - setInitTypeAttributes(other.getInitTypeAttributes()); - setClassInitTypeAttributes(other.getClassInitTypeAttributes()); + if ((sym.flags() & Flags.BRIDGE) != 0) { + Assert.check(other.sym.kind == Kinds.MTH); + ListBuffer typeAttributes = new ListBuffer<>(); + for (TypeCompound tc : other.getTypeAttributes()) { + // Carry over only contractual type annotations: i.e nothing interior to method body. + if (!tc.position.type.isLocal()) + typeAttributes.append(tc); + } + setTypeAttributes(typeAttributes.toList()); + } else { + setTypeAttributes(other.getTypeAttributes()); + } + if (sym.kind == Kinds.TYP) { + setInitTypeAttributes(other.getInitTypeAttributes()); + setClassInitTypeAttributes(other.getClassInitTypeAttributes()); + } } public void setDeclarationAttributesWithCompletion(final Annotate.AnnotateRepeatedContext ctx) { diff -r 7031ed34a604 -r 5dce2796a9c5 test/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java Wed Aug 29 01:34:07 2018 +0200 @@ -0,0 +1,97 @@ +/* + * Copyright (c) 2018, 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 8160928 + * @summary javac incorrectly copies over interior type annotations to bridge method + * @library /tools/javac/lib + * @build ToolBox + * @run compile -g BridgeShouldHaveNoInteriorAnnotationsTest.java + * @run main BridgeShouldHaveNoInteriorAnnotationsTest + */ + +import java.nio.file.Path; +import java.nio.file.Paths; +import java.lang.annotation.ElementType; +import java.lang.annotation.Target; +import java.io.*; + +class Pair_8160928 { +} + +public class BridgeShouldHaveNoInteriorAnnotationsTest implements java.util.Iterator> { + + @Override + public boolean hasNext() { + throw new RuntimeException(); + } + + @Override + public Pair_8160928<@NonNull Object, Object> next() { + Comparable<@NonNull Object> cble1 = (Comparable<@NonNull Object>) null; + return null; + } + + @Override + public void remove() { + throw new RuntimeException(); + } + + @Target(ElementType.TYPE_USE) + public @interface NonNull { + } + + static class OutputExpectedOnceHolder { + public String[] outputs = { + "0: #55(): CAST, offset=0, type_index=0, location=[TYPE_ARGUMENT(0)]", + "1: #55(): LOCAL_VARIABLE, {start_pc=5, length=2, index=1}, location=[TYPE_ARGUMENT(0)]", + }; + } + + static class OutputExpectedTwiceHolder { + public String[] outputs = { + "0: #55(): METHOD_RETURN, location=[TYPE_ARGUMENT(0)]", + }; + } + + public static void main(String[] args) throws Exception { + Path classPath = Paths.get(System.getProperty("test.classes"), "BridgeShouldHaveNoInteriorAnnotationsTest.class"); + String javapOut = ToolBox.javap(new ToolBox.JavaToolArgs().setAllArgs("-v", "-p", classPath.toString())); + + OutputExpectedOnceHolder holder = new OutputExpectedOnceHolder(); + for (String s : holder.outputs) { + String newOutput = javapOut.replace(s, ""); + if (((javapOut.length() - newOutput.length()) / s.length()) != 1) + throw new AssertionError("Interior annotations carried over to bridge ?"); + } + + OutputExpectedTwiceHolder holder2 = new OutputExpectedTwiceHolder(); + for (String s : holder2.outputs) { + String newOutput = javapOut.replace(s, ""); + if (((javapOut.length() - newOutput.length()) / s.length()) != 2) + throw new AssertionError("Exterior annotations not properly carried over to bridge"); + } + } + +} From vicente.romero at oracle.com Thu Aug 30 14:18:38 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 30 Aug 2018 10:18:38 -0400 Subject: JDK-8160928: javac incorrectly copies over interior type annotations to bridge method In-Reply-To: References: Message-ID: <94b8eb2f-a56f-eb7e-9751-2b2bfffdbebe@oracle.com> On 08/30/2018 09:47 AM, Maurizio Cimadamore wrote: > > Hi Vicente, > Is Toolbox available in 8u-dev ? I assume that is why the workaround > has been put in place? > yep, I just did a fresh clone, it is at: test/tools/javac/lib/ToolBox.java > > Maurizio > Vicente > > On 30/08/18 14:36, Vicente Romero wrote: >> why not using ToolBox in the test? We introduced it with the idea of >> using it for these cases >> >> Thanks, >> Vicente >> >> On 08/29/2018 06:33 AM, Evgeny Mandrikov wrote: >>> # HG changeset patch >>> # User Evgeny Mandrikov >>> # Date 1535527073 -7200 >>> # Wed Aug 29 09:17:53 2018 +0200 >>> # Node ID 6dbec1ff0ffcc5a076c08855bb6c5071bab627ee >>> # Parent 7031ed34a60400768d5136df03cbf8f05e6d9a6b >>> 8160928: javac incorrectly copies over interior type annotations to bridge method >>> >>> diff -r 7031ed34a604 -r 6dbec1ff0ffc src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java >>> --- a/src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java Tue Jul 24 09:52:12 2018 -0700 >>> +++ b/src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java Wed Aug 29 09:17:53 2018 +0200 >>> @@ -31,10 +31,13 @@ >>> >>> import com.sun.tools.javac.comp.Annotate; >>> import com.sun.tools.javac.comp.AttrContext; >>> +import com.sun.tools.javac.code.Attribute.TypeCompound; >>> +import com.sun.tools.javac.code.Kinds; >>> import com.sun.tools.javac.comp.Env; >>> import com.sun.tools.javac.util.*; >>> import com.sun.tools.javac.util.Assert; >>> import com.sun.tools.javac.util.List; >>> +import com.sun.tools.javac.util.ListBuffer; >>> import com.sun.tools.javac.util.Log; >>> import com.sun.tools.javac.util.Pair; >>> import static com.sun.tools.javac.code.Kinds.PCK; >>> @@ -152,9 +155,22 @@ >>> throw new NullPointerException(); >>> } >>> setDeclarationAttributes(other.getDeclarationAttributes()); >>> - setTypeAttributes(other.getTypeAttributes()); >>> - setInitTypeAttributes(other.getInitTypeAttributes()); >>> - setClassInitTypeAttributes(other.getClassInitTypeAttributes()); >>> + if ((sym.flags() & Flags.BRIDGE) != 0) { >>> + Assert.check(other.sym.kind == Kinds.MTH); >>> + ListBuffer typeAttributes = new ListBuffer<>(); >>> + for (TypeCompound tc : other.getTypeAttributes()) { >>> + // Carry over only contractual type annotations: i.e nothing interior to method body. >>> + if (!tc.position.type.isLocal()) >>> + typeAttributes.append(tc); >>> + } >>> + setTypeAttributes(typeAttributes.toList()); >>> + } else { >>> + setTypeAttributes(other.getTypeAttributes()); >>> + } >>> + if (sym.kind == Kinds.TYP) { >>> + setInitTypeAttributes(other.getInitTypeAttributes()); >>> + setClassInitTypeAttributes(other.getClassInitTypeAttributes()); >>> + } >>> } >>> >>> public void setDeclarationAttributesWithCompletion(final Annotate.AnnotateRepeatedContext ctx) { >>> diff -r 7031ed34a604 -r 6dbec1ff0ffc test/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java >>> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >>> +++ b/test/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java Wed Aug 29 09:17:53 2018 +0200 >>> @@ -0,0 +1,102 @@ >>> +/* >>> + * Copyright (c) 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 visitwww.oracle.com if you need additional information or have any >>> + * questions. >>> + */ >>> + >>> +/* >>> + * @test >>> + * @bug 8160928 >>> + * @summary javac incorrectly copies over interior type annotations to bridge method >>> + * @run compile -g BridgeShouldHaveNoInteriorAnnotationsTest.java >>> + * @run main BridgeShouldHaveNoInteriorAnnotationsTest >>> + */ >>> + >>> +import java.lang.annotation.ElementType; >>> +import java.lang.annotation.Target; >>> +import java.io.*; >>> + >>> +class Pair_8160928 { >>> +} >>> + >>> +public class BridgeShouldHaveNoInteriorAnnotationsTest implements java.util.Iterator> { >>> + >>> + @Override >>> + public boolean hasNext() { >>> + throw new RuntimeException(); >>> + } >>> + >>> + @Override >>> + public Pair_8160928<@NonNull Object, Object> next() { >>> + Comparable<@NonNull Object> cble1 = (Comparable<@NonNull Object>) null; >>> + return null; >>> + } >>> + >>> + @Override >>> + public void remove() { >>> + throw new RuntimeException(); >>> + } >>> + >>> + @Target(ElementType.TYPE_USE) >>> + public @interface NonNull { >>> + } >>> + >>> + static class OutputExpectedOnceHolder { >>> + public String[] outputs = { >>> + "0: #63(): CAST, offset=0, type_index=0, location=[TYPE_ARGUMENT(0)]", >>> + "1: #63(): LOCAL_VARIABLE, {start_pc=5, length=2, index=1}, location=[TYPE_ARGUMENT(0)]", >>> + }; >>> + } >>> + >>> + static class OutputExpectedTwiceHolder { >>> + public String[] outputs = { >>> + "0: #63(): METHOD_RETURN, location=[TYPE_ARGUMENT(0)]", >>> + }; >>> + } >>> + >>> + public static void main(String[] args) throws Exception { >>> + File testClasses = new File(System.getProperty("test.classes")); >>> + File testClass = new File(testClasses, "BridgeShouldHaveNoInteriorAnnotationsTest.class"); >>> + >>> + StringWriter sw = new StringWriter(); >>> + PrintWriter pw = new PrintWriter(sw); >>> + int rc = com.sun.tools.javap.Main.run(new String[]{"-v", "-p", testClass.getPath()}, pw); >>> + pw.close(); >>> + if (rc != 0) { >>> + throw new Error("javap failed unexpectedly"); >>> + } >>> + String javapOut = sw.toString(); >>> + >>> + OutputExpectedOnceHolder holder = new OutputExpectedOnceHolder(); >>> + for (String s : holder.outputs) { >>> + String newOutput = javapOut.replace(s, ""); >>> + if (((javapOut.length() - newOutput.length()) / s.length()) != 1) >>> + throw new AssertionError("Interior annotations carried over to bridge ?"); >>> + } >>> + >>> + OutputExpectedTwiceHolder holder2 = new OutputExpectedTwiceHolder(); >>> + for (String s : holder2.outputs) { >>> + String newOutput = javapOut.replace(s, ""); >>> + if (((javapOut.length() - newOutput.length()) / s.length()) != 2) >>> + throw new AssertionError("Exterior annotations not properly carried over to bridge"); >>> + } >>> + } >>> + >>> +} >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Thu Aug 30 14:22:36 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 30 Aug 2018 10:22:36 -0400 Subject: JDK-8160928: javac incorrectly copies over interior type annotations to bridge method In-Reply-To: References: Message-ID: <38c821bb-ecc2-d416-9bac-265dc28b10a2@oracle.com> looks good to me, thanks for modifying the patch, Vicente On 08/30/2018 10:16 AM, Evgeny Mandrikov wrote: > Please see updated patch in attachment. > Now it is even less different from original fix. > Tests pass as before. > > > Regards, > Evgeny > > > On Thu, Aug 30, 2018 at 3:58 PM Evgeny Mandrikov > wrote: > > Actually it exists in 8 - > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools/file/7031ed34a604/test/tools/javac/lib/ToolBox.java > > Unfortunately I initially missed this, because of difference in > location/package compared to 9. > Thank you, Vicente, for pointing this out. Will send updated patch > shortly. > > On Thu, Aug 30, 2018 at 3:47 PM Maurizio Cimadamore > > wrote: > > Hi Vicente, > Is Toolbox available in 8u-dev ? I assume that is why the > workaround has been put in place? > > Maurizio > > > On 30/08/18 14:36, Vicente Romero wrote: >> why not using ToolBox in the test? We introduced it with the >> idea of using it for these cases >> >> Thanks, >> Vicente > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicente.romero at oracle.com Fri Aug 31 19:18:25 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 31 Aug 2018 15:18:25 -0400 Subject: RFR: JDK-8207160: ClassReader::adjustMethodParams can potentially return null if the args list is empty Message-ID: Please review the fix for [1] at [2]. The bug was found by a user that was compiling some classes with JDK11 while having some old libs built with JDK6 in the class path. It seems like some versions of javac6 produced constructors for inner classes with no arguments. This is not expected by newer versions of javac and it was producing a NPE. This fix aims at making sure that ClassReader::adjustMethodParams wont return a null even if the list of arguments passed to it is empty. TIA, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8207160 [2] http://cr.openjdk.java.net/~vromero/8207160/webrev.00/jdk.dev.patch From ross.goldberg at gmail.com Fri Aug 31 19:51:19 2018 From: ross.goldberg at gmail.com (Ross Goldberg) Date: Fri, 31 Aug 2018 15:51:19 -0400 Subject: _module-specific form_ for --module-source-path from Bug # 8208609 Message-ID: Can someone provide some details for the _module-specific form_ enhancement for --module-source-path from 8208609? ( https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8208609) Is a _file-path_ always to a file, or could it be to a directory? If directories are supported, are all *.java file descendants compiled with a package hierarchy rooted at the directory? If directories aren't supported, why? The additional error conditions (e.g., 1 _file_path_ being a descendant of another) should be easy to check, and allowing directories could significantly shorten command lines. If a file is included in a module's path via a _file-path_, must the file also be included in the standard _sourcefiles_ arguments? If so, that seems redundant? Will you support {,} alternates in the _module-specific form_? That would also help shorten command lines. Requiring that the module name be specified before the equals sign makes it harder for build systems to use --module-source-path. They must either: 1. parse module-info.java: performance (must parse file), compatibility (might require parser updates if module-info.java spec is changed) 2. read from directory structure based on convention: flexibility (limits layouts) 3. read from build config file: maintenance (config module name must align with module-info.java module name) Could you provide another option, possibly named --module-source, that doesn't require the module name? There should obviously always be one and only one module-info.java in each module's path, so javac should be able to get the module name from that file instead of from the command line. Thanks for any info, Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Fri Aug 31 20:43:39 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 31 Aug 2018 13:43:39 -0700 Subject: _module-specific form_ for --module-source-path from Bug # 8208609 In-Reply-To: References: Message-ID: On 8/31/18 12:51 PM, Ross Goldberg wrote: > Can someone provide some details for the _module-specific form_ > enhancement for --module-source-path from 8208609? > (https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8208609) > > Is a _file-path_ always to a file, or could it be to a directory? By itself, "path" is an overloaded and potentially ambiguous term: it can mean the path for a specific item in a file system (as may be represented by? java.nio.file.Path) or it can mean a search path, like a class path, source path or module path. So I try and qualify which variant I mean. _file-path_ is used to mean a reference to a specific item in the file system.? In the context of the module source path, it probably will be a directory, in which case it should be the directory that is the root of the package hierarchy for some or all of the module's source code. > > If directories are supported, are all *.java file descendants compiled > with a package hierarchy rooted at the directory? Directories, are supported; no, files in the subdirectories are not automatically compiled. That never was (and still is) true for -sourcepath, it is likewise true for the module source path. > > If directories aren't supported, why?? The additional error conditions > (e.g., 1 _file_path_ being a descendant of another) should be easy to > check, and allowing directories could significantly shorten command lines. n/a. See previous answer. > > If a file is included in a module's path via a _file-path_, must the > file also be included in the standard _sourcefiles_ arguments?? If so, > that seems redundant? You put directories on the module source path. You put the specific files to be compiled in the _sourcefiles_ argument.?? While it might seem redundant, it is pragmatically necessary to put the directories on the module source path as well: this is required to help determine the enclosing module, by making it possible to find the corresponding module-info.java file. Note that you only need use --module-source-path when compiling multiple modules at once. If you're just compiling one module at a time, you can use --source-path. > > Will you support {,} alternates in the _module-specific form_?? That > would also help shorten command lines. There are no plans to do that at this time. > > Requiring that the module name be specified before the equals sign > makes it harder for build systems to use --module-source-path. They > must either: > > 1. parse module-info.java: performance (must parse file), > compatibility (might require parser updates if module-info.java spec > is changed) > 2. read from directory structure based on convention: flexibility > (limits layouts) > 3. read from build config file: maintenance (config module name must > align with module-info.java module name) If your files follow the suggested layout, you can use the module-pattern form, which does not require any module name to be specified on the command line.? The module-specific form is for those cases where the file layout does not follow the standard form, in which case it is not unreasonable to specify the name of the module whose source path is being specified. > > Could you provide another option, possibly named --module-source, that > doesn't require the module name? Unlikely.?? It is not clear that there is a problem here that needs to be solved. > > There should obviously always be one and only one module-info.java in > each module's path, so javac should be able to get the module name > from that file instead of from the command line. The current syntax matches that used for the --patch-module option. There is benefit in consistency. There is also benefit in having the user (or build system) explicitly provide the module name, both for documentation and for consistency checking. > > Thanks for any info, Are your concerns related to any specific build system, or to direct use of the javac command in a Makefile or script, or just abstract academic concerns? > > Ross -- Jon