RE: [18][guarded pattern] conditional-and query - spec clarification

tually leading to GuardedPattern ::= PrimaryPattern AND_AND ConditionalAndExpression Regards, Manoj From: Gavin Bierman Date: Friday, 11 March 2022 at 1:51 AM To: Manoj Palat Cc: "amber-spec-experts@openjdk.java.net" Subject: [EXTERNAL] Re: [18][guarded pattern] conditional-and query

[18][guarded pattern] conditional-and query - spec clarification

Hi, Given, public void bar(Object o) { int i = switch(o) { case String a && o != null ? true : false -> 1;//ecj flags syntax error here default -> 1; }; } ECJ(eclipse compiler for Java) flags a syntax error on the guarded pattern. However, javac acc

[JEP 420] Spec Change for switch exhaustive with sealed

Hi Gavin, all, For the issue “Switch coverage with multiple branches” raised in https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-July/003049.html by Dan [yeah – I know it’s a little late to ask this, but still :( ], I couldn’t figure out a spec change in JEP 420 - from the relev

case null and type pattern

Hi Gavin, All, In http://cr.openjdk.java.net/~gbierman/jep406/jep406-20210608/specs/patterns-switch-jls.html#jls-14.30.1, Section 14.11, I see "If a switch label has a null case label element then if the switch label also has any pattern case element labels, they must be type patterns (14.30.1

RE: [records] C-style array declaration of record components - sec 10.2 clarification

-Gavin Bierman wrote: - To: Manoj Palat > Alex is currently integrating the text into the JLS, so I shall make sure > this change is reflected in the final specification. Thanks Gavin! Regards, Manoj

[records] C-style array declaration of record components - sec 10.2 clarification

Hi Gavin, all, >From >http://cr.openjdk.java.net/~gbierman/jep395/jep395-20201204/specs/records-jls.html > (which is the http://cr.openjdk.java.net/~gbierman/jep395/latest as of >writing this), from the section before introduction, we see that : "The changes are the same as those in the second

Re: Sealed interfaces in qualified anonymous class instances - minor spec addition?

Wrong example - Please ignore the earlier mail. realized that this scenario is covered under local classes to flag the error. - sorry for the noise. Regards, Manoj -Manoj Palat/India/IBM wrote: - To: amber-spec-experts@openjdk.java.net From: Manoj Palat/India/IBM Date: 06/20/2020 05

Sealed interfaces in qualified anonymous class instances - minor spec addition?

Hi, >From jep 360 Section 15.9.1 [ >http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200526/specs/sealed-classes-jls.html#jls-15.9.1] > second bullet, ie: “If the class instance creation expression is qualified, then: The Identifier in ClassOrInterfaceTypeToInstantiate must unambiguously denot

RE: Switch Expression - complete normally - spec omission?

Thanks Gavin. Regards Manoj -Gavin Bierman wrote: - To: Manoj Palat From: Gavin Bierman Date: 05/21/2020 07:10PM Cc: amber-spec-experts@openjdk.java.net Subject: [EXTERNAL] Re: Switch Expression - complete normally - spec omission? Thanks Manoj. I’ve filed this as a bug [1] and we’ll

RE: Switch Expression - complete normally - spec omission?

rote: - To: amber-spec-experts@openjdk.java.net From: Alex Buckley Sent by: "amber-spec-experts" Date: 05/15/2020 11:34PM Subject: [EXTERNAL] Re: Switch Expression - complete normally - spec omission? On 5/14/2020 7:22 PM, Manoj Palat wrote: > I think there is a spec omission rega

Switch Expression - complete normally - spec omission?

Hi, I think there is a spec omission regarding "complete normally for switch statements whose switch block consists of switch rules Ref JLS 14 Sec 14.22 ... A switch statement whose switch block consists of switch rules can complete normally iff at least one of the following is true: – One of the

RE: Swiss Cheese Issue - Revisit?

d to select among more than one candidate is bad for us - and probably bad for users, too. More than one candidate is to imply: depending on flow either could be legal.   Regards, Manoj.   - Original message -----From: Brian Goetz To: Manoj Palat , fo...@univ-mlv.frCc: amber-spec-experts@openjdk

RE: Swiss Cheese Issue - Revisit?

ss Cheese Issue - Revisit?   De: "Brian Goetz" À: "Remi Forax" Cc: "Manoj Palat" , "amber-spec-experts" Envoyé: Mercredi 6 Mai 2020 16:41:33Objet: Re: Swiss Cheese Issue - Revisit? I think I get what you are saying, but we didn't go out of our way to _sup

Swiss Cheese Issue - Revisit?

Hi Brian, Gavin, all, Referring to Tagir’s example in [1]     if (obj instanceof String str) {     System.out.println(str.toLowerCase()); // str refers to pattern binding     } else {     System.out.println(str.toLowerCase()); // str refers to the field     } which is me

RE: Final issues regarding records

Hi All,    #1. Accessibility of various record members.   Would prefer option 3 -  Incorporate both strategies.    #2. Annotating explicit accessor methods  Would prefer option 2 - Co-op `@Override`-  here.   Regards, Manoj - Original message -From: Brian Goetz Sent by: "amber-spec-experts"

Re: [records] propogating modifiers for implicit methods

Resending by removing the link as I see it "scrubbed"   Hi,  (a) Given a record,  record R(int a){}, I see the (implicit) final modifiers propagated to implicit methods hashCode() and equals()    [javap output] public final boolean equals(java.lang.Object);  However, toString() does not get the sam

[records] propogating modifiers for implicit methods

Hi,  (a) Given a record,  record R(int a){}, I see the (implicit) final modifiers propagated to implicit methods hashCode() and equals()    [javap output] public final boolean equals(java.lang.Object);  However, toString() does not get the same ->    public java.lang.String toString(); (b)  Adding

RE: [359] Record - Compact Constructor should not have throws clause

Sure. I see JDK-8238838  filed.    Thanks, Manoj - Original message -From: Vicente Romero To: Tagir Valeev , Manoj Palat Cc: amber-spec-experts Subject: [EXTERNAL] Re: [359] Record - Compact Constructor should not have throws clauseDate: Tue, Feb 11, 2020 9:47 AM  On the spec side I agree

[359] Record - Compact Constructor should not have throws clause

Hi, consider record R(){ public R throws Exception {} } >From JLS 14 Sec 8.10.4, A canonical constructor must not have a throws clause. Sec 8.10.5 says A compact constructor is a canonical constructor. By the above two, it can be inferred that a compact constructor must not have

Pattern instanceof Variable JEP clarification

Hi Gavin,   From section 6.3 of http://cr.openjdk.java.net/~gbierman/jep305/jep305-20191021/specs/patterns-instanceof-jls.html, in the following statement:   "The scope of a pattern variable is determined by considering the innermost enclosing statement S that contains the pattern variable declarat

RE: New candidate JEP: 361: Switch Expressions (Standard)

Hi Gavin,   For the record, JEP 361 Switch Expressions draft looks fine - we have started to make the preview-to-standard transition of Switch Expressions in Eclipse on the basis of this, already.   Thanks, Manoj Eclipse Java Dev, IBM.   - Original message -From: Gavin Bierman Sent by: "amb

Re: Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in expression switch)

I would vote for option E - a real keyword : break-with. Regards, Manoj From: Guy Steele To: Brian Goetz Cc: amber-spec-experts Date: 05/18/2019 12:11 AM Subject:[EXTERNAL] Re: Yield as contextual keyword (was: Call for bikeshed -- break replacement in express

Re: Re: Call for bikeshed -- break replacement in expression switch

Hi, I have a few points regarding this – since there was a flurry of mails last night/day, I have given references below to specific threads below: -As Maurizio pointed out in https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-May/001334.html , “yield” is not really a _reserved_type_i

Re: Switch expressions spec

Hi Alex, Gavin, A few comments/clarifications: 1: In section, 14.15 The break Statement A break statement transfers control out of an enclosing statement, or causes an enclosing switchexpression to produce a specified value. BreakStatement: break [~~ Identifier ~~] ; break E