From gavin.bierman at oracle.com Tue May 2 22:17:19 2023 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 2 May 2023 22:17:19 +0000 Subject: Draft Spec for Unnamed Classes and Instance main Methods (JEP 445) Message-ID: <245CD9A3-DFBF-4F3A-9805-3F4667A2C0BD@oracle.com> Dear experts: The first draft of the spec change document for the feature Unnamed classes and instance main methods [1] (the "on-ramp" feature) is now available at: https://cr.openjdk.org/~gbierman/jep445/latest/ Please give us your feedback (either on this list or directly to me). Thanks, Gavin [1] Unnamed classes and instance main methods: https://openjdk.org/jeps/445 From amaembo at gmail.com Wed May 3 13:55:23 2023 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 3 May 2023 15:55:23 +0200 Subject: Draft Spec for Unnamed Classes and Instance main Methods (JEP 445) In-Reply-To: <245CD9A3-DFBF-4F3A-9805-3F4667A2C0BD@oracle.com> References: <245CD9A3-DFBF-4F3A-9805-3F4667A2C0BD@oracle.com> Message-ID: Hello! Great job, thank you! To me, the discussion in "7.3 Compilation Units" section looks confusing. It's written: An unnamed top level class compilation unit consists of: ... - The declarations of the members of the implicitly declared top level class, at least one of which is a field declaration (8.3) or a method declaration (8.4). ... the following is unambiguously an unnamed top level class compilation unit: import p.*; int count = 0; class Test {} And below: > It is a compile-time error if this class does not declare a candidate main method (12.1.4). So the first obvious problem is that the sample above is not a valid Java program, as it lacks the main method. And if it's not a valid Java program, it looks like there is no reason to classify whether this particular sample is an unnamed compilation unit, or named one. It's up to the tool which compilation error to issue here: lack of main method in unnamed compilation unit or misplaced variable declaration in ordinary compilation unit. I'm inclined to think that the latter would be less confusing, but apparently this is up to the tool implementation. Smart tools may suggest both fixes: either move the `count` declaration into class or declare the `main` method. As a candidate main method must present and it cannot be inherited from super-class/super-interface (due to the absence of them), it looks like we can simplify this part: An unnamed top level class compilation unit consists of: - zero or more import declarations that allow classes and interface from other packages, and static members of classes and interfaces, to be referred to using their simple names. - The declarations of the members of the implicitly declared top level class, at least one of which is a candidate main method (12.1.4). No field mention is necessary at all. And the sample should be updated accordingly, like import p.*; class Test {} void main() {} What do you think? With best regards, Tagir Valeev. On Wed, May 3, 2023 at 12:17?AM Gavin Bierman wrote: > > Dear experts: > > The first draft of the spec change document for the feature Unnamed classes and instance main methods [1] (the "on-ramp" feature) is now available at: > > https://cr.openjdk.org/~gbierman/jep445/latest/ > > Please give us your feedback (either on this list or directly to me). > > Thanks, > Gavin > > [1] Unnamed classes and instance main methods: https://openjdk.org/jeps/445 From archie.cobbs at gmail.com Wed May 3 14:23:04 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Wed, 3 May 2023 09:23:04 -0500 Subject: Draft Spec for Unnamed Classes and Instance main Methods (JEP 445) In-Reply-To: <245CD9A3-DFBF-4F3A-9805-3F4667A2C0BD@oracle.com> References: <245CD9A3-DFBF-4F3A-9805-3F4667A2C0BD@oracle.com> Message-ID: I think this will be a nice addition. On Tue, May 2, 2023 at 5:17?PM Gavin Bierman wrote: > The first draft of the spec change document for the feature Unnamed > classes and instance main methods [1] (the "on-ramp" feature) is now > available at: > > https://cr.openjdk.org/~gbierman/jep445/latest/ 1. Minor nit: "An unnamed top level class compilation unit implicitly declares an class..." - should be "a class". 2. Just to clarify my own understanding, is this correct? "Unnamed top level class" is a source code only concept; given a class file, it is not possible to definitively say whether it came from an "unnamed top level class". 3. The JEP shows an example of compiling a class "HelloWorld.java" into a class file "HelloWorld.java" and states "In this case the compiler chooses HelloWorld for the class name as an implementation detail". So far, so good. But then in the spec it says: In simple implementations of the Java SE Platform, where compilation units > are stored in files, the binary name of an unnamed top level class would > typically be the name of the file containing the unnamed top level class > compilation unit (7.3 > > ). > That would imply that the binary name of the JEP example would be "HelloWorld.java", not "HelloWorld". So maybe to clarify this should say "the name of the file (minus the ".java" suffix) containing the unnamed top level class compilation unit". -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Wed May 3 15:20:37 2023 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Wed, 3 May 2023 15:20:37 +0000 Subject: Draft Spec for Unnamed Classes and Instance main Methods (JEP 445) In-Reply-To: References: <245CD9A3-DFBF-4F3A-9805-3F4667A2C0BD@oracle.com> Message-ID: <2606B58C-3F60-4C10-A99E-78E075E22659@oracle.com> Thanks Archie and Tagir. I have updated the spec. Gavin On 3 May 2023, at 15:23, Archie Cobbs wrote: I think this will be a nice addition. On Tue, May 2, 2023 at 5:17?PM Gavin Bierman > wrote: The first draft of the spec change document for the feature Unnamed classes and instance main methods [1] (the "on-ramp" feature) is now available at: https://cr.openjdk.org/~gbierman/jep445/latest/ 1. Minor nit: "An unnamed top level class compilation unit implicitly declares an class..." - should be "a class". 2. Just to clarify my own understanding, is this correct? "Unnamed top level class" is a source code only concept; given a class file, it is not possible to definitively say whether it came from an "unnamed top level class". 3. The JEP shows an example of compiling a class "HelloWorld.java" into a class file "HelloWorld.java" and states "In this case the compiler chooses HelloWorld for the class name as an implementation detail". So far, so good. But then in the spec it says: In simple implementations of the Java SE Platform, where compilation units are stored in files, the binary name of an unnamed top level class would typically be the name of the file containing the unnamed top level class compilation unit (7.3). That would imply that the binary name of the JEP example would be "HelloWorld.java", not "HelloWorld". So maybe to clarify this should say "the name of the file (minus the ".java" suffix) containing the unnamed top level class compilation unit". -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.smith at oracle.com Thu May 4 21:43:20 2023 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 4 May 2023 21:43:20 +0000 Subject: Record pattern inference & capture In-Reply-To: <05E51BDD-F0BA-481E-A73B-5C5A4EC49ECB@oracle.com> References: <05E51BDD-F0BA-481E-A73B-5C5A4EC49ECB@oracle.com> Message-ID: <5E5FDC3E-20A7-4063-B252-783E013573B8@oracle.com> > On Mar 24, 2023, at 3:00 PM, Dan Smith wrote: > > If I try to match the type Function with a type like UnaryOperator, should that be an inference failure? The current rules say "yes": inference variable alpha=CAP1, and alpha=CAP2, a contradiction. But I don't think that's right. If the dynamic check for UnaryOperator succeeds, that means that this must actually be a Function in which the actual types represented by CAP1 and CAP2 are the same. Followup: in fact, this is also true for type variables: void test(Function f) { if (f instanceof Mapper(var in, var out)) ... } It is certainly possible for this test to succeed?if, say, S and T are instantiated to some subtype of Foo and Bar. (This is why it's perfectly legal since Java 5 to cast from Function to Mapper.) Unfortunately, if we were to give type variables the same treatment as wildcards, what we'd end up inferring is Mapper, which is not as useful as Mapper or Mapper. And setting these complex use cases aside, it would be disappointing if, given Collection as a match input, we couldn't infer MyRecordList as its subtype and ended up with MyRecordList instead. (It might also be useful to sometimes preserve capture variables in the inferred type in simple cases, although there's some complexity there?compare JDK-8170887.) I'm unsure about the right way to resolve this tension. Best I can come up with is a heuristic-based "try with the variables, then if that fails try turning all variables into inference vars" strategy, but I don't love bringing yet more of that kind of logic into type inference. From cay.horstmann at gmail.com Sun May 7 09:19:36 2023 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Sun, 7 May 2023 10:19:36 +0100 Subject: Remarks on JEP 430 Message-ID: Here are some remarks on JEP 430, collected from discussions at the JAlba unconference. * The interface name java.lang.StringTemplate was strongly felt to be confusing. An instance neither processes nor produces Strings. Suggestion: java.lang.Template, matching the grammar. * Given that several programming languages use the syntax processor"..." without a dot, it would be helpful to have a rationale for the dot following the template processor. The parenthetical "as seen in other kinds of expressions" is not helpful. Obviously, in other kinds of expressions, the dot is followed by field or method names, which are not at all the same thing. Suggestion: Give a more cogent rationale, or drop the dot * The RAW processor will confuse JavaScript and Scala programmers. Suggestion: TEMPLATE * Suggestion: Change the heading "String interpolation is dangerous" to "String interpolation can be dangerous", and "Interpolation is especially dangerous for SQL statements" to "Interpolation is dangerous for SQL statements" * The section "User-defined template processors" gives a rationale why STR is written in uppercase. That rationale does not hold for the processors named INTER, INTERN, JSON, DB, THAI, LOCALIZE below. Suggestion: Write those in lowercase, or declare them as final. * The example of the INTER processor with placeHolder "?" is obviously dangerous and adds no real value. Suggestion: Drop it and start with the subsequent example. Cheers, Cay -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From gavin.bierman at oracle.com Tue May 9 21:13:04 2023 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 9 May 2023 21:13:04 +0000 Subject: Draft Spec for Pattern Matching for switch (JEP 441) and Record Patterns (JEP 440) now available In-Reply-To: <74893015-FD27-44AA-84FD-375BC240DF89@oracle.com> References: <74893015-FD27-44AA-84FD-375BC240DF89@oracle.com> Message-ID: <3CB5283B-B74D-400A-A117-94FA817BF60D@oracle.com> FYI I have uploaded a new draft of the joint spec change document. Two main changes: 1. I have updated the specification of type inference for record patterns per Dan?s email [*] 2. I have removed the non-denotable ?any? patterns and the process of resolving patterns in favour of a compile-time notion of a type pattern being ?null-matching? or not. (This is purely a specification improvement and has no semantic content.) https://cr.openjdk.org/~gbierman/jep440+441/latest/ Thanks, Gavin [*] https://mail.openjdk.org/pipermail/amber-spec-experts/2023-March/003808.html On 7 Apr 2023, at 22:28, Gavin Bierman wrote: Dear experts: The first draft of the joint spec change document for the features Pattern Matching for switch [1] and Record Patterns [2] is now available at: https://cr.openjdk.org/~gbierman/jep440+441/latest/ Please give us your feedback (either on this list or directly to me). Thanks, Gavin [1] Pattern matching for switch: https://openjdk.org/jeps/441 [2] Record patterns: https://openjdk.org/jeps/440 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Fri May 12 09:08:02 2023 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Fri, 12 May 2023 09:08:02 +0000 Subject: [Resend] Draft Spec for Statements before Super() (JEP 447) In-Reply-To: <0A605E48-05AA-4EE2-8861-5E50225A7336@oracle.com> References: <7405ACA9-C88D-4170-A758-714B6F9CBD27@oracle.com> <0A605E48-05AA-4EE2-8861-5E50225A7336@oracle.com> Message-ID: The latest draft of the spec change document for JEP 447 (Statements before super()) is available at: https://cr.openjdk.org/~gbierman/jep447/latest/ Gavin On 20 Apr 2023, at 22:29, Gavin Bierman wrote: Third time lucky: Dear experts: The first draft of the spec change document for the feature Statements before super() [1] is now available at: https://cr.openjdk.org/~gbierman/jep447/latest/ Please give us your feedback (either on this list or directly to me). Thanks, Gavin [1] Statements before super(): https://openjdk.org/jeps/447 On 20 Apr 2023, at 22:26, Gavin Bierman wrote: [Resending as the hyperlinks got mangled] Dear experts: The first draft of the spec change document for the feature Statements before super() [1] is now available at: https://cr.openjdk.org/~gbierman/jep447/latest/ Please give us your feedback (either on this list or directly to me). Thanks, Gavin [1] Statements before super(): https://openjdk.org/jeps/447 -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Mon May 15 16:49:11 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Mon, 15 May 2023 11:49:11 -0500 Subject: JEP 447 Statements before super() - Preview feature? Message-ID: The following question came up and needs opinions from this list... JEP 447 Statements before super() is currently not specified as a preview feature... should it be? On the one hand, language changes are usually previewed first; on the other hand, this change is fairly simple and straightforward. Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Mon May 15 17:13:38 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 15 May 2023 13:13:38 -0400 Subject: JEP 447 Statements before super() - Preview feature? In-Reply-To: References: Message-ID: <0db67155-4196-7474-daca-d977bd9a1e4e@oracle.com> I agree that this one is at the edge of what we would need to preview, and so I can see going either way here.? Since we've never done a non-preview language feature since the advent of preview, we kind of have to face the problem here and decide not only for this feature, but on guidelines going forward.? So far, we've been following the implicit policy of "all language features go through preview" (I could easily imagine relaxing this to exclude things that are effectively language bugfixes.) On the one hand, previewing adds some cost and work.? It means extra code in the compiler, extra tests, and then more work and another JEP to finalize it.? On the other, preview is a valuable mechanism for getting feedback on a feature before being stuck with it forever. One notable thing about *this* JEP is that, even when everyone agreed on the scope and the approach, the spec still required a few rounds of iteration to get it right.? That suggests that even given its narrow focus, there are still potentially some demons lurking. On 5/15/2023 12:49 PM, Archie Cobbs wrote: > The following question came up and needs opinions from this list... > > JEP 447 Statements before super() is currently not specified as a > preview feature... should it be? > > On the one hand, language changes are usually previewed first; on the > other hand, this change is fairly simple and straightforward. > > Thanks, > -Archie > > -- > Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Mon May 15 17:16:28 2023 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Mon, 15 May 2023 17:16:28 +0000 Subject: Draft Spec for Unnamed Classes and Instance main Methods (JEP 445) In-Reply-To: <245CD9A3-DFBF-4F3A-9805-3F4667A2C0BD@oracle.com> References: <245CD9A3-DFBF-4F3A-9805-3F4667A2C0BD@oracle.com> Message-ID: <8A043793-B84F-4194-98CD-5A914D94E720@oracle.com> During the CSR process it was observed that this feature requires some (small) changes to the JVMS. I have made this spec change document, which is linked from the header of the language spec change document updated at: https://cr.openjdk.org/~gbierman/jep445/latest/ Thanks, Gavin On 2 May 2023, at 23:17, Gavin Bierman wrote: Dear experts: The first draft of the spec change document for the feature Unnamed classes and instance main methods [1] (the "on-ramp" feature) is now available at: https://cr.openjdk.org/~gbierman/jep445/latest/ Please give us your feedback (either on this list or directly to me). Thanks, Gavin [1] Unnamed classes and instance main methods: https://openjdk.org/jeps/445 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Mon May 15 18:47:47 2023 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 15 May 2023 11:47:47 -0700 Subject: JEP 447 Statements before super() - Preview feature? In-Reply-To: <0db67155-4196-7474-daca-d977bd9a1e4e@oracle.com> References: <0db67155-4196-7474-daca-d977bd9a1e4e@oracle.com> Message-ID: <30c31974-322c-6b84-129e-5faad9b395bc@oracle.com> I am certain there are some demons lurking, and I am even more certain that we will be surprised by the interactions of language constructs within a ctor body that give rise to them. In fact, I would like to see the JEP spend less time rehearsing JLS modifications and more time exploring how tools, analyzers, linters, etc will be impacted by ctor bodies that have a prologue. The Risks & Assumptions section should be pages long. And I will pose another question: are there any tricks, idioms, or 'patterns' that have been necessary in Java code to workaround the super()-comes-first rule? I would like the Motivation or Description (or both) to complement the currently rather abstract story (about superclasses, guarantees, and top-down initialization) with some straightforward code samples of what developers had to write before and why it was error-prone and why it hurt maintainability. Now that the JEP is stable as a Candidate, it's legitimate for Archie, as owner, to enhance the text in these ways. Given the likelihood of dotting i's and crossing t's in the design/spec, and in the hope that the JEP can get quite a bit richer, I think at least one round of preview is the right thing to do. Alex On 5/15/2023 10:13 AM, Brian Goetz wrote: > I agree that this one is at the edge of what we would need to preview, > and so I can see going either way here.? Since we've never done a > non-preview language feature since the advent of preview, we kind of > have to face the problem here and decide not only for this feature, but > on guidelines going forward.? So far, we've been following the implicit > policy of "all language features go through preview" (I could easily > imagine relaxing this to exclude things that are effectively language > bugfixes.) > > On the one hand, previewing adds some cost and work.? It means extra > code in the compiler, extra tests, and then more work and another JEP to > finalize it.? On the other, preview is a valuable mechanism for getting > feedback on a feature before being stuck with it forever. > > One notable thing about *this* JEP is that, even when everyone agreed on > the scope and the approach, the spec still required a few rounds of > iteration to get it right.? That suggests that even given its narrow > focus, there are still potentially some demons lurking. > > > > On 5/15/2023 12:49 PM, Archie Cobbs wrote: >> The following question came up and needs opinions from this list... >> >> JEP 447 Statements before super() is currently not specified as a >> preview feature... should it be? >> >> On the one hand, language changes are usually previewed first; on the >> other hand, this change is fairly simple and straightforward. >> >> Thanks, >> -Archie >> >> -- >> Archie L. Cobbs > From guy.steele at oracle.com Mon May 15 20:00:51 2023 From: guy.steele at oracle.com (Guy Steele) Date: Mon, 15 May 2023 20:00:51 +0000 Subject: [Resend] Draft Spec for Statements before Super() (JEP 447) In-Reply-To: References: <7405ACA9-C88D-4170-A758-714B6F9CBD27@oracle.com> <0A605E48-05AA-4EE2-8861-5E50225A7336@oracle.com> Message-ID: Thank you. Overall looks good. Detailed comments: 8.8.7. In the BNF for ConstructorBody, in the second alternative, I believe that no brackets should appear around ExplicitConstructorInvocation: { [BlockStatements] [ExplicitConstructorInvocation] [BlockStatements] } should be { [BlockStatements] ExplicitConstructorInvocation [BlockStatements] } In the second paragraph, in "an invocation of the constructor of its direct superclass? I believe the word ?its? should be ?the?. The fourth paragraph defines the phrase ?prologue of [the/a] constructor body?, but the fifth paragraph twice uses the phrase ?prologue of a constructor?, which is not defined. 12.5 In the list of six steps for processing a constructor, the logic is a bit difficult to follow because of nonparallelism, recapitulation, and a mixture of explicit ?goto? instructions with drop-through. I suggest this refactored structure: 1. Assign the arguments for the constructor to newly created parameter variables for this constructor invocation. 2. If this constructor does not contain an explicit constructor invocation (8.8.7.1), go to step 4; otherwise, continue with step 3. 3. Execute the BlockStatements, if any, of the prologue of the constructor body. If execution of any statement completes abruptly, then execution of the constructor completes abruptly for the same reason; otherwise, continue with step 4. 4. If this constructor does not contain an explicit constructor invocation (8.8.7.1), go to step 6; otherwise, continue with step 5. 5. Evaluate the arguments of the explicit constructor invocation?it may be an invocation of of another constructor in the same class (using this) or an invocation of a superclass constructor (using super)?and process that constructor invocation recursively using this same nine-step procedure. If that constructor invocation completes abruptly, then this procedure completes abruptly for the same reason; otherwise, go to step 8. 6. If this constructor is a constructor for class Object, go to step 8; otherwise continue with step 7. 7. This constructor contains an implicit invocation super(); of a superclass constructor with no arguments. Process that superclass constructor invocation recursively using this same nine-step procedure. If that constructor invocation completes abruptly, then this procedure completes abruptly for the same reason. Otherwise, continue with step 8. 8. Execute the instance initializers and instance variable initializers for this class, assigning the values of instance variable initializers to the corresponding instance variables, in the left-to-right order in which they appear textually in the source code for the class. If execution of any of these initializers results in an exception, then no further initializers are processed and this procedure completes abruptly with that same exception. Otherwise, continue with step 9. 9. Execute the BlockStatements, if any, of the epilogue of this constructor. If execution of any statement completes abruptly, then this procedure completes abruptly for the same reason. Otherwise, this procedure completes normally. Hope this helps. ?Guy On May 12, 2023, at 5:08 AM, Gavin Bierman wrote: The latest draft of the spec change document for JEP 447 (Statements before super()) is available at: https://cr.openjdk.org/~gbierman/jep447/latest/ Gavin On 20 Apr 2023, at 22:29, Gavin Bierman wrote: Third time lucky: Dear experts: The first draft of the spec change document for the feature Statements before super() [1] is now available at: https://cr.openjdk.org/~gbierman/jep447/latest/ Please give us your feedback (either on this list or directly to me). Thanks, Gavin [1] Statements before super(): https://openjdk.org/jeps/447 On 20 Apr 2023, at 22:26, Gavin Bierman wrote: [Resending as the hyperlinks got mangled] Dear experts: The first draft of the spec change document for the feature Statements before super() [1] is now available at: https://cr.openjdk.org/~gbierman/jep447/latest/ Please give us your feedback (either on this list or directly to me). Thanks, Gavin [1] Statements before super(): https://openjdk.org/jeps/447 -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Mon May 15 20:41:56 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Mon, 15 May 2023 15:41:56 -0500 Subject: [Resend] Draft Spec for Statements before Super() (JEP 447) In-Reply-To: References: <7405ACA9-C88D-4170-A758-714B6F9CBD27@oracle.com> <0A605E48-05AA-4EE2-8861-5E50225A7336@oracle.com> Message-ID: On Mon, May 15, 2023 at 3:00?PM Guy Steele wrote: > 12.5 In the list of six steps for processing a constructor, the logic is a > bit difficult to follow because of nonparallelism, recapitulation, and a > mixture of explicit ?goto? instructions with drop-through. I suggest this > refactored structure: > That's a nice cleanup - thanks. It looks like step 4 is redundant: > 1. Assign the arguments for the constructor to newly created parameter > variables for this constructor invocation. > > 2. If this constructor does not contain an explicit constructor > invocation (8.8.7.1), go to step 4; otherwise, continue with step 3. > > 3. Execute the BlockStatements, if any, of the prologue of the > constructor body. If execution of any statement completes abruptly, then > execution of the constructor completes abruptly for the same reason; > otherwise, continue with step 4. > > 4. If this constructor does not contain an explicit constructor > invocation (8.8.7.1), go to step 6; otherwise, continue with step 5. > So step 4 can be removed, and step 2 can "goto step 6" (of course once step 4 is removed, steps 5+ get renumbered so that change ultimately becomes "goto step 5"). -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Mon May 15 20:56:50 2023 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Mon, 15 May 2023 20:56:50 +0000 Subject: JEP 447 Statements before super() - Preview feature? In-Reply-To: References: Message-ID: <92E6A7CD-DEFC-46A4-8960-751BA89362ED@oracle.com> Whilst the change is reasonably simple, I strongly believe that we should preview this feature. The great thing of preview is that it allows people time to try out prototypes before we fix a feature *for all time*. Gavin On 15 May 2023, at 17:49, Archie Cobbs wrote: The following question came up and needs opinions from this list... JEP 447 Statements before super() is currently not specified as a preview feature... should it be? On the one hand, language changes are usually previewed first; on the other hand, this change is fairly simple and straightforward. Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From guy.steele at oracle.com Mon May 15 21:16:47 2023 From: guy.steele at oracle.com (Guy Steele) Date: Mon, 15 May 2023 21:16:47 +0000 Subject: [Resend] Draft Spec for Statements before Super() (JEP 447) In-Reply-To: References: <7405ACA9-C88D-4170-A758-714B6F9CBD27@oracle.com> <0A605E48-05AA-4EE2-8861-5E50225A7336@oracle.com> Message-ID: Oh, right?thanks for this correction. ?Guy On May 15, 2023, at 4:41 PM, Archie Cobbs wrote: On Mon, May 15, 2023 at 3:00?PM Guy Steele > wrote: 12.5 In the list of six steps for processing a constructor, the logic is a bit difficult to follow because of nonparallelism, recapitulation, and a mixture of explicit ?goto? instructions with drop-through. I suggest this refactored structure: That's a nice cleanup - thanks. It looks like step 4 is redundant: 1. Assign the arguments for the constructor to newly created parameter variables for this constructor invocation. 2. If this constructor does not contain an explicit constructor invocation (8.8.7.1), go to step 4; otherwise, continue with step 3. 3. Execute the BlockStatements, if any, of the prologue of the constructor body. If execution of any statement completes abruptly, then execution of the constructor completes abruptly for the same reason; otherwise, continue with step 4. 4. If this constructor does not contain an explicit constructor invocation (8.8.7.1), go to step 6; otherwise, continue with step 5. So step 4 can be removed, and step 2 can "goto step 6" (of course once step 4 is removed, steps 5+ get renumbered so that change ultimately becomes "goto step 5"). -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.laskey at oracle.com Mon May 15 21:20:11 2023 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 15 May 2023 21:20:11 +0000 Subject: JEP 447 Statements before super() - Preview feature? In-Reply-To: <92E6A7CD-DEFC-46A4-8960-751BA89362ED@oracle.com> References: <92E6A7CD-DEFC-46A4-8960-751BA89362ED@oracle.com> Message-ID: <6A1810F2-E7C7-417B-BEB2-72AB76E65A81@oracle.com> I can help set up the preview bits in the compiler if you like. ? On May 15, 2023, at 5:57 PM, Gavin Bierman wrote: ? Whilst the change is reasonably simple, I strongly believe that we should preview this feature. The great thing of preview is that it allows people time to try out prototypes before we fix a feature *for all time*. Gavin On 15 May 2023, at 17:49, Archie Cobbs wrote: The following question came up and needs opinions from this list... JEP 447 Statements before super() is currently not specified as a preview feature... should it be? On the one hand, language changes are usually previewed first; on the other hand, this change is fairly simple and straightforward. Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Mon May 15 21:49:28 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Mon, 15 May 2023 16:49:28 -0500 Subject: JEP 447 Statements before super() - Preview feature? In-Reply-To: <6A1810F2-E7C7-417B-BEB2-72AB76E65A81@oracle.com> References: <92E6A7CD-DEFC-46A4-8960-751BA89362ED@oracle.com> <6A1810F2-E7C7-417B-BEB2-72AB76E65A81@oracle.com> Message-ID: Hi Jim, That would be great - thanks for the offer. The latest working code is on the amber "super-init" branch if you want to check it out (pun intended). Thanks, -Archie On Mon, May 15, 2023 at 4:20?PM Jim Laskey wrote: > I can help set up the preview bits in the compiler if you like. > > ? > > On May 15, 2023, at 5:57 PM, Gavin Bierman > wrote: > > ? Whilst the change is reasonably simple, I strongly believe that we > should preview this feature. The great thing of preview is that it allows > people time to try out prototypes before we fix a feature **for all > time*. * > > Gavin > > On 15 May 2023, at 17:49, Archie Cobbs wrote: > > The following question came up and needs opinions from this list... > > JEP 447 Statements before super() is currently not specified as a preview > feature... should it be? > > On the one hand, language changes are usually previewed first; on the > other hand, this change is fairly simple and straightforward. > > Thanks, > -Archie > > -- > Archie L. Cobbs > > > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Wed May 17 12:33:29 2023 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 17 May 2023 14:33:29 +0200 (CEST) Subject: JEP 443: semantics of "case _" vs "case null, default" Message-ID: <866818833.57278057.1684326809975.JavaMail.zimbra@univ-eiffel.fr> Hello, all, I've reread the JEP 443, https://cr.openjdk.org/~abimpoudis/unnamed/jep443-20230322/specs/unnamed-jls.html First, a minor nit, at the end of the section 14.30.1, there is this sentence that reference the section 14.30.1 ! "An unnamed pattern is always null-matching (14.30.1)." My brain, stackoverflowed on that :) And now a question, with the introduction of the unnamed pattern, in a switch, "case _" and "case null, default" have the same semantics, given that "case null, default" is a kind of a hack, should we still allow it ? regards, R?mi From brian.goetz at oracle.com Wed May 17 15:25:57 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 17 May 2023 11:25:57 -0400 Subject: JEP 443: semantics of "case _" vs "case null, default" In-Reply-To: <866818833.57278057.1684326809975.JavaMail.zimbra@univ-eiffel.fr> References: <866818833.57278057.1684326809975.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On 5/17/2023 8:33 AM, Remi Forax wrote: > Hello, all, > I've reread the JEP 443, > https://cr.openjdk.org/~abimpoudis/unnamed/jep443-20230322/specs/unnamed-jls.html > > First, a minor nit, at the end of the section 14.30.1, there is this sentence that reference the section 14.30.1 ! > "An unnamed pattern is always null-matching (14.30.1)." > > My brain, stackoverflowed on that :) This is a minor shuffling of terminology, but nothing really has changed. Previously we recorded the difference between a partial and total type pattern (which differ at their null matching) through a process of resolving an unconditional pattern to an "any" pattern.? The any pattern was a figment of the specification, and didn't correspond to anything in the language (yet).? Now that we have underscore patterns, which might well be called "any" patterns, the terminology was confusing so we adjusted the terms, to those that will likely serve us better in the future.? But the semantics are still what they always were. > And now a question, with the introduction of the unnamed pattern, in a switch, "case _" and "case null, default" have the same semantics, > given that "case null, default" is a kind of a hack, should we still allow it ? > This is actually two questions: ?- should we still allow `case null, default` (current answer: yes) ?- should we allow `case _` (current answer: no) If the answer to the second is no, there is no question that we should continue to say yes to the first. I think given the long history of null-hostility of switch, giving people both `case _` and `default` at the top level will make more trouble than it solves, so the status quo seems OK to me. From forax at univ-mlv.fr Wed May 17 15:58:58 2023 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 17 May 2023 17:58:58 +0200 (CEST) Subject: JEP 443: semantics of "case _" vs "case null, default" In-Reply-To: References: <866818833.57278057.1684326809975.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1245661517.57503963.1684339138034.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Brian Goetz" > To: "Remi Forax" , "amber-spec-experts" > Cc: "Gavin Bierman" > Sent: Wednesday, May 17, 2023 5:25:57 PM > Subject: Re: JEP 443: semantics of "case _" vs "case null, default" > On 5/17/2023 8:33 AM, Remi Forax wrote: >> Hello, all, >> I've reread the JEP 443, >> https://cr.openjdk.org/~abimpoudis/unnamed/jep443-20230322/specs/unnamed-jls.html >> >> First, a minor nit, at the end of the section 14.30.1, there is this sentence >> that reference the section 14.30.1 ! >> "An unnamed pattern is always null-matching (14.30.1)." >> >> My brain, stackoverflowed on that :) > > This is a minor shuffling of terminology, but nothing really has changed. > > Previously we recorded the difference between a partial and total type > pattern (which differ at their null matching) through a process of > resolving an unconditional pattern to an "any" pattern.? The any pattern > was a figment of the specification, and didn't correspond to anything in > the language (yet).? Now that we have underscore patterns, which might > well be called "any" patterns, the terminology was confusing so we > adjusted the terms, to those that will likely serve us better in the > future.? But the semantics are still what they always were. > >> And now a question, with the introduction of the unnamed pattern, in a switch, >> "case _" and "case null, default" have the same semantics, >> given that "case null, default" is a kind of a hack, should we still allow it ? >> > > This is actually two questions: > > ?- should we still allow `case null, default` (current answer: yes) > ?- should we allow `case _` (current answer: no) > > If the answer to the second is no, there is no question that we should > continue to say yes to the first. > > I think given the long history of null-hostility of switch, giving > people both `case _` and `default` at the top level will make more > trouble than it solves, so the status quo seems OK to me. So like "case var o" is not allowed. It's OK for me too, I did not know (or forget) that case _ was not allowed. R?mi From guy.steele at oracle.com Thu May 18 02:19:07 2023 From: guy.steele at oracle.com (Guy Steele) Date: Thu, 18 May 2023 02:19:07 +0000 Subject: JEP 443: semantics of "case _" vs "case null, default" In-Reply-To: References: <866818833.57278057.1684326809975.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <7A56117A-F059-44E3-820B-CF719D8534DC@oracle.com> > On May 17, 2023, at 11:25 AM, Brian Goetz wrote: > > > > On 5/17/2023 8:33 AM, Remi Forax wrote: >> Hello, all, >> I've reread the JEP 443, >> https://cr.openjdk.org/~abimpoudis/unnamed/jep443-20230322/specs/unnamed-jls.html >> >> First, a minor nit, at the end of the section 14.30.1, there is this sentence that reference the section 14.30.1 ! >> "An unnamed pattern is always null-matching (14.30.1)." >> >> My brain, stackoverflowed on that :) > > This is a minor shuffling of terminology, but nothing really has changed. > > Previously we recorded the difference between a partial and total type pattern (which differ at their null matching) through a process of resolving an unconditional pattern to an "any" pattern. The any pattern was a figment of the specification, and didn't correspond to anything in the language (yet). Now that we have underscore patterns, which might well be called "any" patterns, the terminology was confusing so we adjusted the terms, to those that will likely serve us better in the future. But the semantics are still what they always were. > >> And now a question, with the introduction of the unnamed pattern, in a switch, "case _" and "case null, default" have the same semantics, >> given that "case null, default" is a kind of a hack, should we still allow it ? >> > > This is actually two questions: > > - should we still allow `case null, default` (current answer: yes) > - should we allow `case _` (current answer: no) > > If the answer to the second is no, there is no question that we should continue to say yes to the first. > > I think given the long history of null-hostility of switch, giving people both `case _` and `default` at the top level will make more trouble than it solves, so the status quo seems OK to me. Yes, for the rare cases where one needs to say it, the purpose of "case null, default:? will be easier to understand for most readers than ?case _:?. From archie.cobbs at gmail.com Thu May 18 17:16:34 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 18 May 2023 12:16:34 -0500 Subject: JEP 447 Statements before super() - Preview feature? In-Reply-To: <30c31974-322c-6b84-129e-5faad9b395bc@oracle.com> References: <0db67155-4196-7474-daca-d977bd9a1e4e@oracle.com> <30c31974-322c-6b84-129e-5faad9b395bc@oracle.com> Message-ID: Hi Alex, On Mon, May 15, 2023 at 1:47?PM Alex Buckley wrote: > In fact, I would like to see the JEP spend less time rehearsing JLS > modifications We are planning to remove all the JLS specification changes - they belong in the CSR instead (this distinction was not clear to me at first). more time exploring how tools, analyzers, linters, etc > will be impacted by ctor bodies that have a prologue. The Risks & > Assumptions section should be pages long. > Can you elaborate on why you think this is needed? Of course, it's obviously true that any change to the language is going to affect analyzers, linters, and other such tools. So the question is whether this needs to be explicitly noted. I was gauging this based on what I've seen in other JEP's. For example, JEP 378 Text Blocks includes no such discussion, yet that change has a clear impact on such tools. And I will pose another question: are there any tricks, idioms, or > 'patterns' that have been necessary in Java code to workaround the > super()-comes-first rule? I would like the Motivation or Description (or > both) to complement the currently rather abstract story (about > superclasses, guarantees, and top-down initialization) with some > straightforward code samples of what developers had to write before and > why it was error-prone and why it hurt maintainability. > This was the goal of the section starting with "the current rule causes idioms commonly used within normal methods to be either difficult or impossible to use within constructors. Below are a few examples." Let me know if you think these examples are unclear. Thanks, -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Thu May 18 19:25:33 2023 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 18 May 2023 12:25:33 -0700 Subject: [External] : Re: JEP 447 Statements before super() - Preview feature? In-Reply-To: References: <0db67155-4196-7474-daca-d977bd9a1e4e@oracle.com> <30c31974-322c-6b84-129e-5faad9b395bc@oracle.com> Message-ID: Hi Archie, On 5/18/2023 10:16 AM, Archie Cobbs wrote: > On Mon, May 15, 2023 at 1:47?PM Alex Buckley > wrote: > > In fact, I would like to see the JEP spend less time rehearsing JLS > modifications > > We are planning to remove all the JLS specification changes - they > belong in the CSR instead (this distinction was not clear to me at first). Yes. Also, the Non-Goals are mostly expressed in terms of specs, which isn't right since specs are an "implementation detail" of the feature ... the Non-Goals should focus on what the end user (a developer) will see or not see. Finally, almost no-one will be able to figure out what this means -- "There are many ways in which the interplay between superclass constructors and subclass initialization might be improved" -- so please either explain (in a very small space) or remove. > more time exploring how tools, analyzers, linters, etc > will be impacted by ctor bodies that have a prologue. The Risks & > Assumptions section should be pages long. > > Can you elaborate on why you think this is needed? > > Of course, it's obviously true that any change to the language is going > to affect analyzers, linters, and other such tools. So the question is > whether this needs to be explicitly noted. > > I was gauging this based on what I've seen in other JEP's. For example, > JEP 378 Text Blocks includes no such > discussion, yet that change has a clear impact on such tools. A JEP should be a 360-degree explanation of a feature. It's where the feature owner acknowledges the _vast_ numbers of people and software who are downstream of (in this case) a Java language construct and will be affected by the feature. For example, here's a StackOverflow question about ctor invocation with >1MM views: https://stackoverflow.com/questions/285177/how-do-i-call-one-constructor-from-another-in-java/285184#285184 See how all the top answers make a point of noting that `super(..)`/`this(..)` must appear first! I'm not saying you should add a Risk of "All the answers on StackOverflow will be invalidated." I'm saying that millions of lines of code exist because people explicitly coded around the restriction you're now removing, so there's a huge amount of refactoring that is (a) possible and (b) desirable, so we _assume_ that static analyzers and IDEs will promote this refactoring to their users. If you don't say this in the JEP, no-one will know it. No-one knows as much as you about this feature, so please share :-) As to JEP 378 (and others), it is unsatisfactory that there's no "Risks and Assumptions" section. We try to do better with each JEP and each release, but there are _many_ JEPs in flight for 21 so time has been limited. Still, JEP 447 is _changing_ a very longstanding and well known construct, so is on the hook more than other JEPs for documenting its risks and assumptions ... if it says more now, then it'll be setting a good example for future JEPs. > And I will pose another question: are there any tricks, idioms, or > 'patterns' that have been necessary in Java code to workaround the > super()-comes-first rule? I would like the Motivation or Description > (or > both) to complement the currently rather abstract story (about > superclasses, guarantees, and top-down initialization) with some > straightforward code samples of what developers had to write before and > why it was error-prone and why it hurt maintainability. > > This was the goal of the section starting with "the current rule causes > idioms commonly used within normal methods to be either difficult or > impossible to use within constructors. Below are a few examples." Let me > know if you think these examples are unclear. I'm sorry, I don't know how I missed the "Implementing fail-fast" subsection and its siblings. You show three idioms where the restriction on code before `super(..)` has little purpose and impedes understanding. (I'm sure someone will be along soon to tell us that HotSpot will inline a static method like `verifyPositive`, but that won't make the code review which questions the method's existence go any quicker, and reviewers' time is more expensive than machine time.) I would like to enrich the "Implementing fail-fast" subsection by acknowledging the fine idiom of _telescoping constructors_, where simpler constructors delegate to richer constructors by using `this(..)` to pass default arguments (see https://stackoverflow.com/a/285187). In any intermediate constructor of non-zero arity, being able to check the arguments before delegation could be useful. Ironically, this might resurrect a static helper to check `arg1` and `arg2`, because the checks can occur in both the intermediate constructor(s) and the richest constructor. (You can imagine the StackOverflow questions that will emerge about how much failing-fast to do in the prologue. Brian used to say that yesterday's solutions are today's problems ... well, today's solutions are tomorrow's StackOverflow questions. The JEP's role is to get out in front of the developer community by acknowledging new idioms and, ideally, making recommendations. Anything you put in the JEP will be eagerly consumed by JLS authors looking to have sample code and conventions in non-normative spec text! I hope I'm being clear that where the JEP leads, _everyone_ else follows.) Thank you for the very good work on JEP 447 so far. Alex From alex.buckley at oracle.com Thu May 18 19:33:32 2023 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 18 May 2023 12:33:32 -0700 Subject: [Resend] Draft Spec for Statements before Super() (JEP 447) In-Reply-To: References: <7405ACA9-C88D-4170-A758-714B6F9CBD27@oracle.com> <0A605E48-05AA-4EE2-8861-5E50225A7336@oracle.com> Message-ID: On 5/12/2023 2:08 AM, Gavin Bierman wrote: > The latest draft of the spec change document for JEP 447 (Statements > before super()) is available at: > > https://cr.openjdk.org/~gbierman/jep447/latest/ From thinking about telescoping constructors in another mail, I think there's an omission in the draft. In the JEP, https://openjdk.org/jeps/447#Records says "The net result is that non-canonical record constructors may now contain prologue statements before this()." However, the draft does not address how JLS20, at https://docs.oracle.com/javase/specs/jls/se20/html/jls-8.html#jls-8.10.4-500 says "A record declaration may contain declarations of constructors that are not canonical constructors. The body of every non-canonical constructor in a record declaration must *start with* an alternate constructor invocation (?8.8.7.1), or a compile-time error occurs." I assume the intent is to allow a non-canonical ctor in a record declaration to *contain* an alternate ctor invocation, not just *start with*? If so, please amend 8.10.4 in the draft. Alex From archie.cobbs at gmail.com Thu May 18 22:56:19 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 18 May 2023 17:56:19 -0500 Subject: [External] : Re: JEP 447 Statements before super() - Preview feature? In-Reply-To: References: <0db67155-4196-7474-daca-d977bd9a1e4e@oracle.com> <30c31974-322c-6b84-129e-5faad9b395bc@oracle.com> Message-ID: Hi Alex, Great comments, thanks.... On Thu, May 18, 2023 at 2:25?PM Alex Buckley wrote: > ... the Non-Goals should focus on what the end user (a developer) will > see or not see. Finally, almost no-one will be able to figure out what > this means -- "There are many ways in which the interplay between > superclass constructors and subclass initialization might be improved" > -- so please either explain (in a very small space) or remove. > Agreed - removed. I'm saying that millions of lines of code exist because people explicitly > coded around the restriction you're now removing, so there's a huge > amount of refactoring that is (a) possible and (b) desirable, so we > _assume_ that static analyzers and IDEs will promote this refactoring to > their users. If you don't say this in the JEP, no-one will know it. > No-one knows as much as you about this feature, so please share :-) > Good point.. I've added some more verbiage to Risks & Assumptions. I also added some language to highlight the fact that this "pre-construction" context we are creating is not really new - the rules are the same as already apply to the this()/super() parameter expressions. So hopefully that is a big hint to any tool providers that they already know how to treat the code in the constructor prologue. > I would like to enrich the "Implementing fail-fast" subsection by > acknowledging the fine idiom of _telescoping constructors_, where > simpler constructors delegate to richer constructors by using `this(..)` > to pass default arguments (see https://stackoverflow.com/a/285187). In > any intermediate constructor of non-zero arity, being able to check the > arguments before delegation could be useful. > "Telescoping constructors" is definitely a worthy use case for this feature... I like that and have added it. And a good real-world example comes from none other than java.lang.Thread. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Thu May 18 23:53:29 2023 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 18 May 2023 16:53:29 -0700 Subject: [External] : Re: JEP 447 Statements before super() - Preview feature? In-Reply-To: References: <0db67155-4196-7474-daca-d977bd9a1e4e@oracle.com> <30c31974-322c-6b84-129e-5faad9b395bc@oracle.com> Message-ID: <47c76a22-feb0-eb42-dc7e-b31e496cc9c8@oracle.com> Hi Archie, Your updates to the JEP are excellent in every way. Thank you. Alex On 5/18/2023 3:56 PM, Archie Cobbs wrote: > Hi Alex, > > Great comments, thanks.... > > On Thu, May 18, 2023 at 2:25?PM Alex Buckley > wrote: > > ... the Non-Goals should focus on what the end user (a developer) will > see or not see. Finally, almost no-one will be able to figure out what > this means -- "There are many ways in which the interplay between > superclass constructors and subclass initialization might be improved" > -- so please either explain (in a very small space) or remove. > > > Agreed - removed. > > I'm saying that millions of lines of code exist because people > explicitly > coded around the restriction you're now removing, so there's a huge > amount of refactoring that is (a) possible and (b) desirable, so we > _assume_ that static analyzers and IDEs will promote this > refactoring to > their users. If you don't say this in the JEP, no-one will know it. > No-one knows as much as you about this feature, so please share :-) > > > Good point.. I've added some more verbiage to Risks & Assumptions. > > ?I also added some language to highlight the fact that this > "pre-construction" context we are creating is not really new - the rules > are the same as already apply to the this()/super() parameter expressions. > > So hopefully that is a big hint to any tool providers that they already > know how to treat the code in the constructor prologue. > > I would like to enrich the "Implementing fail-fast" subsection by > acknowledging the fine idiom of _telescoping constructors_, where > simpler constructors delegate to richer constructors by using > `this(..)` > to pass default arguments (see https://stackoverflow.com/a/285187 > ). In > any intermediate constructor of non-zero arity, being able to check the > arguments before delegation could be useful. > > > "Telescoping constructors" is definitely a worthy use case for this > feature... I like that and have added it. > > And a good real-world example comes from none other than java.lang.Thread. > > -Archie > > -- > Archie L. Cobbs From archie.cobbs at gmail.com Fri May 19 01:36:49 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Thu, 18 May 2023 20:36:49 -0500 Subject: [External] : Re: JEP 447 Statements before super() - Preview feature? In-Reply-To: <47c76a22-feb0-eb42-dc7e-b31e496cc9c8@oracle.com> References: <0db67155-4196-7474-daca-d977bd9a1e4e@oracle.com> <30c31974-322c-6b84-129e-5faad9b395bc@oracle.com> <47c76a22-feb0-eb42-dc7e-b31e496cc9c8@oracle.com> Message-ID: Hi Alex, Thanks for your thoughtful review & comments. -Archie On Thu, May 18, 2023 at 6:53?PM Alex Buckley wrote: > Hi Archie, > > Your updates to the JEP are excellent in every way. Thank you. > > Alex > > On 5/18/2023 3:56 PM, Archie Cobbs wrote: > > Hi Alex, > > > > Great comments, thanks.... > > > > On Thu, May 18, 2023 at 2:25?PM Alex Buckley > > wrote: > > > > ... the Non-Goals should focus on what the end user (a developer) > will > > see or not see. Finally, almost no-one will be able to figure out > what > > this means -- "There are many ways in which the interplay between > > superclass constructors and subclass initialization might be > improved" > > -- so please either explain (in a very small space) or remove. > > > > > > Agreed - removed. > > > > I'm saying that millions of lines of code exist because people > > explicitly > > coded around the restriction you're now removing, so there's a huge > > amount of refactoring that is (a) possible and (b) desirable, so we > > _assume_ that static analyzers and IDEs will promote this > > refactoring to > > their users. If you don't say this in the JEP, no-one will know it. > > No-one knows as much as you about this feature, so please share :-) > > > > > > Good point.. I've added some more verbiage to Risks & Assumptions. > > > > I also added some language to highlight the fact that this > > "pre-construction" context we are creating is not really new - the rules > > are the same as already apply to the this()/super() parameter > expressions. > > > > So hopefully that is a big hint to any tool providers that they already > > know how to treat the code in the constructor prologue. > > > > I would like to enrich the "Implementing fail-fast" subsection by > > acknowledging the fine idiom of _telescoping constructors_, where > > simpler constructors delegate to richer constructors by using > > `this(..)` > > to pass default arguments (see https://stackoverflow.com/a/285187 > > < > https://urldefense.com/v3/__https://stackoverflow.com/a/285187__;!!ACWV5N9M2RV99hQ!O-9cBnMpSBttTFUwyTA_mphXNEnUrb691HNu5nTJkieZQZMkA1UgNTyTpWa05uE-RnIz8ZnI_-8soiSv_GkKYHs1Sw$>). > In > > any intermediate constructor of non-zero arity, being able to check > the > > arguments before delegation could be useful. > > > > > > "Telescoping constructors" is definitely a worthy use case for this > > feature... I like that and have added it. > > > > And a good real-world example comes from none other than > java.lang.Thread. > > > > -Archie > > > > -- > > Archie L. Cobbs > -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From cay.horstmann at gmail.com Fri May 26 10:32:59 2023 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Fri, 26 May 2023 12:32:59 +0200 Subject: var _ vs _ Message-ID: With JDK build 24, the following works: record Point(int x, int y) {} ... Point p = ...; String description = switch (p) { case Point(var x, var _) when x == 0 -> "on y-axis"; case Point(_, var y) when y == 0 -> "on x-axis"; case Point(var _, var _) -> "something else"; }; But this switch is not deemed exhaustive: String description = switch (p) { case Point(var x, var _) when x == 0 -> "on y-axis"; case Point(_, var y) when y == 0 -> "on x-axis"; case Point(_, _) -> "something else"; }; Is that a bug, or is there some subtle difference between var _ and _? Thanks, Cay -- -- Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com From archie.cobbs at gmail.com Tue May 30 15:39:54 2023 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 30 May 2023 10:39:54 -0500 Subject: [Resend] Draft Spec for Statements before Super() (JEP 447) In-Reply-To: References: <7405ACA9-C88D-4170-A758-714B6F9CBD27@oracle.com> <0A605E48-05AA-4EE2-8861-5E50225A7336@oracle.com> Message-ID: On Thu, May 18, 2023 at 2:33?PM Alex Buckley wrote: > However, the draft does not address how JLS20, at > > > https://docs.oracle.com/javase/specs/jls/se20/html/jls-8.html#jls-8.10.4-500 > > says > > "A record declaration may contain declarations of constructors that are > not canonical constructors. The body of every non-canonical constructor > in a record declaration must *start with* an alternate constructor > invocation (?8.8.7.1), or a compile-time error occurs." > > I assume the intent is to allow a non-canonical ctor in a record > declaration to *contain* an alternate ctor invocation, not just *start > with*? If so, please amend 8.10.4 in the draft. > Good catch - I agree that changing "start with" to "contain" is the right fix. Gavin, will you update the spec draft please? -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: