Re: The Record Attribute - What does it mean to be a record at runtime?

On 11/10/2020 1:09 PM, fo...@univ-mlv.fr wrote: *De: *"Chris Hegarty" *À: *"Remi Forax" *Cc: *"amber-spec-experts" *Envoyé: *Mardi 10 Novembre 2020 21:51:38 *Objet: *Re: The Record Attribute - What does it mean to be a record at runtime? Remi, A point of

Re: Next up for patterns: type patterns in switch

On 7/23/2020 11:52 AM, Brian Goetz wrote: On 7/23/2020 2:38 PM, Remi Forax wrote: On guards, they do not work well with exhaustiveness. Still not sure they are useful. It works fine, it's just more work for the user to get right. We induce a domination ordering on patterns.  If `T <: U`,

Re: Switch Expression - complete normally - spec omission?

On 5/14/2020 7:22 PM, Manoj Palat wrote: 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

Re: Class & interface terminology

On 5/7/2020 4:19 PM, Alex Buckley wrote: We ought to be able to represent the taxonomy in a table, where any combination of row title and column title gives something meaningful: | Declaration |  Type - Class C

Re: Class & interface terminology

On 5/7/2020 3:24 PM, Dan Smith wrote: Are you comfortable with the tension between "annotation interface declaration" and "enum declaration", or do we need to keep pulling on the string to get "enum class declaration"? As weird as "annotation interface declaration" is, there has to be some

Re: Class & interface terminology

On 5/7/2020 2:29 PM, Dan Smith wrote: Is there a particular part of JLS that you think should be rephrased to reflect these assertions? No, I just wanted to get the assertions on the record in email, so they could be added to the discussion at the start of the Consistent Terminology spec. 10

Re: Class & interface terminology

On 5/7/2020 11:48 AM, Dan Smith wrote: I'll add that it's useful to think in terms of three different entities: 1) Class and interface declarations. These are syntax. Example: "interface List ..." 2) Classes and interfaces. These are "symbols". Example: the interface List 3) Class and

Re: [sealed] Runtime checking of PermittedSubtypes

On 4/22/2020 4:32 PM, Dan Smith wrote: Another module system sanity check: is mutual recursion allowed between unnamed modules of different loaders? (Pre-9, mutual recursion between different loaders was certainly possible...) Yes. Anything that was possible with class loaders on JDK 8 is

Re: [sealed] Runtime checking of PermittedSubtypes

On 4/22/2020 4:15 PM, Dan Smith wrote: Okay, so it would be valid to talk about "the run-time module of C" while C is being derived? I think this sentence from 5.3.6 anticipates this sort of early query, but I might be misinterpreting the parenthetical: "We say that a class is in a run-time

Re: [sealed] Runtime checking of PermittedSubtypes

On 4/22/2020 1:43 PM, Remi Forax wrote: 2a) If the superclass belongs to a different run-time module, error. 2b) If the superclass doesn't have the subclass's name in its PermittedSubtypes, error. 2b doesn't need to load anything, because 2a has guaranteed that both classes have the same

Re: JLS question regarding Text Blocks

On 4/6/2020 11:43 AM, Jim Laskey wrote: In section 3.10.6 Text Blocks of the updated spec; "The opening delimiter is a sequence that starts with three double quote characters ("""), continues with zero or more space, tab, and form feed characters, and concludes with a line terminator."

Re: @since specification for preview features

Thanks Jim. I recorded this policy in JEP 12, under "Relationship to Java SE APIs": "The API developer must also add an @since tag that indicates the release when @preview was first added. (If the essential API element is eventually made final and permanent in Java SE $Z, then the @since tag

Re: Clarifying record reflective support

On 12/3/2019 8:49 AM, Dan Smith wrote: So, Fine: "isRecord returns true if the class extends java.lang.Record and has a Record attribute." (a little more detailed than most reflection methods, but that's probably good) Overkill: "isRecord returns true if the class extends java.lang.Record and

Re: Clarifying record reflective support

On 12/3/2019 8:39 AM, John Rose wrote: On Dec 3, 2019, at 8:31 AM, Alex Buckley <mailto:alex.buck...@oracle.com>> wrote: For example, if the Record.components[i].attributes table contains a Signature attribute, then that's fine per Table 4.7-C; but if said table contains a Code

Re: Clarifying record reflective support

On 12/3/2019 8:35 AM, John Rose wrote: I have two concerns concerning JVM behavior: 1. Keep class file loading fast and simple. Don’t go beyond precedent in structure checking. The current implementation is good from this POV; it just ensures basic referential integrity at the constant pool

Re: Clarifying record reflective support

On 12/3/2019 6:24 AM, Chris Hegarty wrote: At least from the JVM side of things, one could lean on the JVMS, Section 4.1 “The ClassFile Structure”. While the draft records JVMS does amend various sections and subsections of Chapter 4, it does not touch section 4.1. Reading between the lines, I

Re: Updated Draft specs for JEP 359 (Records)

On 11/27/2019 12:59 AM, Gavin Bierman wrote: I don't see any changes to http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html ? Should be there now. This updated JVMS draft looks good, thanks. Alex

Re: Updated Draft specs for JEP 359 (Records)

On 11/26/2019 8:48 AM, Dan Smith wrote: Here's my slightly-tweaked version of this note: It is a limitation of the `class` file that, while a method parameter or a module may be marked `ACC_MANDATED` ([4.7.24], [4.7.25]), there is no equivalent way to flag compiler-generated methods and

Re: Updated Draft specs for JEP 359 (Records)

Updated JLS draft looks good, thanks. On 11/26/2019 6:17 AM, Gavin Bierman wrote: Thanks Alex; have made these changes to the online version. Gavin

Re: Updated Draft specs for JEP 359 (Records)

// Cutting amber-dev On 11/25/2019 3:23 PM, Gavin Bierman wrote: http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html The JLS draft is good. Some technical rewordings: 1. 8.10.3: "and the type as the declared type" -- missing a "same" 2. 8.10.3: Say "This field

Re: Updated Draft specs for JEP 359 (Records)

// Cutting amber-dev On 11/25/2019 3:23 PM, Gavin Bierman wrote: http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html The JVMS draft is good. It should have an informative note in 4.7.8: "It is an oversight in the design of the `class` file that there is no way

Re: Updated Draft specs for JEP 359 (Records)

On 11/25/2019 12:42 PM, Dan Smith wrote: On Nov 6, 2019, at 11:21 AM, Alex Buckley wrote: For spec clarity, please rename `component_info` to `record_component_info`. I hadn't seen this comment, but I've now applied this change as requested (will show up next time Gavin posts an update

Re: Spec: ACC_MANDATED

On 11/22/2019 12:10 PM, Jonathan Gibbons wrote: Could someone also specify definitively the behavior when a user chooses to explicitly define a method, such as `equals` or `hashCode` for a record.   In other words, just because a method may be mandated in JLS, I'm expecting that this does not

Re: Spec: ACC_MANDATED

(Removing compiler-dev. Cross-posting to *-dev and *-spec-experts list is wrong. We're discussing a question driven mainly by Records, so let's treat it as Amber spec territory.) On 11/22/2019 12:02 PM, Dan Smith wrote: On Nov 22, 2019, at 12:22 PM, Leonid Kuskov wrote: Does it make sense to

Re: Spec: ACC_MANDATED

(This question was asked internally, and it wasn't clear if it was about JEP 359 (Records) specifically or ACC_MANDATED more broadly. Since the question is being driven by JEP 359 changes, and since JEP 359 is in any case the next feature which will change the JVMS, let's discuss on

Re: Updated Draft specs for JEP 359 (Records)

On 11/21/2019 7:01 AM, Gavin Bierman wrote: A hopefully final draft language spec for JEP 359 (Records) is available at: http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191121/specs/records-jls.html This incorporates (I hope!) all the very helpful suggestions from everyone on these lists

Re: Updated Draft specs for JEP 359 (Records)

On 10/31/2019 7:17 AM, Gavin Bierman wrote: (Alongside is a draft JVM spec for this feature: http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191031/specs/records-jvms.html ) I looked at this for the CSR JDK-8233595. The `component_info` structure which is mentioned all over the place

Re: Updated Draft specs for JEP 359 (Records)

On 11/4/2019 12:50 PM, Florian Weimer wrote: I think we are looking at different versions of the spec. I don't see either wording here: But the updated wording works for me. Doh, you're right,

Re: Updated Draft specs for JEP 359 (Records)

Florian, Thanks for drawing attention to this part of the spec: On 11/2/2019 3:21 AM, Florian Weimer wrote: Is it allowed to declare a canonical constructor explicitly and make it non-public? I think the naswer is no. But it's not quite obvious from the spec, I think. JLS 8.10.4 defines a

Re: Fields and methods of a record are marked MANDATED

Enum types are specified such that a `values` method is always implicitly declared. (If you declare one explicitly, you have two method declarations with override-equivalent signatures, which is an error per JLS 8.4.) Accordingly, the corresponding method in the class file should always be

Re: Exploring inference for sealed types

You speak of "compilation unit" as if it means the scope of work performed by javac and Maven. ("compiles each module separately as its own compilation unit") That's not the meaning. The meaning is as given in https://docs.oracle.com/javase/specs/jls/se13/html/jls-7.html#jls-7.3 On 10/2/2019

Re: record components as a first class reflection element

At first glance, this is sensible because of the first-class status in the JLS of record components and their mapping to accessors. Based on a check of other implementations of AnnotatedElement, consider `boolean isVarArgs()` (IIRC a varargs component will be allowed) and `String

Re: Draft JLS spec for records

Let me comment on Maurizio's comments, and add some more. In 1.1, the spec for enum types has been used as a template, which is fine, but the summary of enum types has always been poor: the singular/plural construction is weird, and the mixing of kinds (class v. object) is horrible. The JLS

Re: Refinements for sealed types

// Declarations of RedFruit/BlueFruit corrected below from `extends Node` to `extends Fruit` I don't know what I don't know about "aux classes". I do know that if you don't nest the concrete leaves, they can't be public in the same compilation unit: --Fruit.java-- public sealed interface

Re: Refinements for sealed types

On 8/20/2019 3:45 PM, Brian Goetz wrote: This seems reasonable too, because most concrete classes in such hierarchies _will be_ leaves. In this world, though, it feels a little inconsistent to only do this when the subclass and the sealed type are in the same compilation unit; we could extend

Re: Refinements for sealed types

On 8/20/2019 12:40 PM, Brian Goetz wrote: Gathering the various threads in this discussion, here’s what seems a sensible landing place: 1. A sealed _class_ with no permitted subtypes is a final class. The distinction between declared-sealed-with-no-permits and declared-final is erased

Re: Refinements for sealed types

On 8/19/2019 3:22 PM, Brian Goetz wrote: I don't have a strong opinion on whether "sealed but no permitted subtypes" is a habitable space separate from "final", but I'm fine to say "that means final" for most purposes. Not sure what reflection should say; is it OK for a type that is clearly

Re: Refinements for sealed types

On 8/19/2019 11:52 AM, Brian Goetz wrote: How do you know from `sealed class X {}` and the rest of its compilation unit that all X's subtypes are co-declared? By co-declared, I mean "in the same compilation unit." The emphasis should be on the word "all", not "co-declared". How do you know

Re: Refinements for sealed types

On 8/19/2019 11:27 AM, Brian Goetz wrote: So, given all this, we should focus all our ceremony-reduction on the case of co-declared sum types.  Which is mostly what I think I was suggesting:   - Infer the permits clause when all the subtypes are co-declared;   - Infer “final” for leaf classes

Re: Refinements for sealed types

On 8/18/2019 12:25 PM, Brian Goetz wrote: So, given all this, we should focus all our ceremony-reduction on the case of co-declared sum types.  Which is mostly what I think I was suggesting:  - Infer the permits clause when all the subtypes are co-declared;  - Infer “final” for leaf classes

Re: Draft specification for java.lang.Record

On 8/15/2019 12:18 PM, Brian Goetz wrote: Cloning: if a record class was to implement Cloneable, then the inherited implementation of Object::clone would not preserve copy equality (because, yes, cloning is not the same as copying). Recommend not implementing Cloneable? We have an

Re: Refinements for sealed types

On 8/15/2019 10:38 AM, Brian Goetz wrote:     sealed interface X permits A, B { }     class A implements X { }     class B implements X { } In the current design, we took the following path:  - Subtypes of sealed types are implicitly sealed, unless marked non-sealed.  - We infer a

Re: Draft specification for java.lang.Record

I am reading this javadoc from the POV of someone in 2034 (15 years hence, like we are 15 years from Enum) who doesn't know anything about Amber. On 8/15/2019 10:34 AM, Brian Goetz wrote: /**  * This is the common base class of all Java language record classes. I know this borrows from

Re: Escape Sequences For Managing Whitespace (Preview)

- Title: "Escape Sequences for Line Continuation and White Space (Preview)" (the narrative term is "white space" per the JLS and JEP 355; the only time the ` ` character after "white" is missing is in the name of the grammar production WhiteSpace) - Goal: "Improve the the observability of

Re: Programmer's Guide To Text Blocks

On 8/5/2019 5:37 AM, Jim Laskey wrote: http://cr.openjdk.java.net/~jlaskey/Strings/TextBlocksGuide_v8.html - Please number the guidelines like in the var style guidelines. - "Guideline: If a string literal fits on a single line" -- A string literal CAN ONLY fit on a single line; you mean "If

Re: Draft language spec for JEP 355: Text Blocks

On 5/29/2019 9:57 AM, Arthur Neufeld wrote: String season = """ winter """; // the six characters w i n t e r Doesn’t “season” actually contain 7 characters? w i n t e r \n Good catch, thanks. Yes, seven characters. The final character is a line

Re: Yield as contextual keyword

nalysis, as reported by Brian, shows this not to be a problem. Tagir’s analysis of the Idea Ultimate sources suggests the same. The revised JLS is available at: http://cr.openjdk.java.net/~gbierman/jep354-jls-20190528.html Thanks, Gavin On 24 May 2019, at 23:44, Alex Buckley mailto:alex.buck...@oracl

Re: Yield as contextual keyword

On 5/24/2019 1:19 PM, Tagir Valeev wrote: Hello! Answering myself The first token in a YieldStatement production is always preceded by one of these separator tokens: ;, {, }, ), or ->. Seems I'm missing something. Could you please illustrate in which case YieldStatement could be preceded by

Re: Yield as contextual keyword

On 5/23/2019 2:29 PM, Dan Smith wrote: 2) Type names: 'yield' might be used as the name of a class, type of a method parameter, type of a field, array component type, type of a 'final' local variable etc. Or we can prohibit it entirely as a type name. We went through this when designing 'var',

Re: Draft language spec for JEP 355: Text Blocks

On 5/21/2019 5:51 AM, Brian Goetz wrote: As string literals get longer, the cost-benefit of interning get worse, and eventually turn negative; it is super-unlikely that two compilation units will use the same 14-line snippet of JSON (no benefit), and at the same time, we’re taking up much more

Re: Draft language spec for JEP 355: Text Blocks

On 5/21/2019 5:30 AM, Jim Laskey wrote: TextBlock: " " " { the ASCII SP character } LineTerminator { TextBlockCharacter } " " " "the ASCII SP character" in the open delimiter is currently implemented as any "white space" but not a line terminator. Later on you state "zero or more white

Draft language spec for JEP 355: Text Blocks

Please see http://cr.openjdk.java.net/~abuckley/jep355/text-blocks-jls.html for JLS changes that align with the JEP. Text blocks compile to the same class file construct as string literals, namely CONSTANT_String_info entries in the constant pool. Helpfully, the JVMS is already agnostic

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

Correction: `yield-value` is a hyphenated keyword. Specifically, a hyphenated contextual keyword, where each term is itself a unitary contextual keyword. This is discussed, with examples, in the JEP (https://openjdk.java.net/jeps/8223002). Introducing `yield-value` as a hyphenated contextual

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

On 5/16/2019 2:05 PM, Maurizio Cimadamore wrote: There are other contexts in which we limit what can be done w/r/t/ parenthesized expressions (since these are ambiguous with cast to generic types). So this looks like another case where the grammar has to say - sorry no parens here. If you're

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

On 5/16/2019 8:24 AM, Brian Goetz wrote: We’ve probably pretty much explored the options at this point; time to converge around one of the choices... I am very happy with `yield` as the new construct for concluding the evaluation of a switch expression and leaving a value on the stack for

Re: RFR: Multi-line String Literal (Preview) JEP [EG Draft]

On 5/15/2019 10:17 AM, Dan Smith wrote: I think this: ~~~ String code = """ public void print(""" + type + """ o) { System.out.println(Objects.toString(o)); } """; ~~~ should be presented like this: ~~~ String

Re: String reboot - (1a) incidental whitespace

On 4/22/2019 12:16 PM, Guy Steele wrote: On Apr 22, 2019, at 3:04 PM, Alex Buckley wrote: Nope, I don't think multi-line string literals are an attractive nuisance in any way. We should NOT deem it incorrect to refactor a sequence of concatenations into a single multi-line string literal. I

Re: To align, or not to align?

On 4/18/2019 11:32 AM, Brian Goetz wrote: One view is that a string literal is the sequence of characters between the delimiters, and a multi-line string literal is just a string literal that happens to be able to span lines. This is also the simplest extension of existing string literals to

Re: String reboot - (1a) incidental whitespace

On 4/10/2019 8:22 AM, Jim Laskey wrote: Line terminators: When strings span lines, they do so using the line terminators present in the source file, which may vary depending on what operating system the file was authored. Should this be an aspect of multi-line-ness, or should we normalize

Re: String reboot (plain text)

On 4/5/2019 7:15 AM, Jim Laskey wrote: Following example works as expected: public class Test { public static void main(String... args) { String result = """ public class Main { public static void main(String... args) {

Re: Switch expressions spec

lex, There are negative tests with missed result expressions: From: Leonid Arbuzov To: Alex Buckley , amber-spec-experts Cc: Stephan Herrmann Date: 03/21/2019 06:35 AM Subject: Re: Switch expressions spec Sent by: "amber-spec-experts" --

Re: Switch expressions spec

of range, etc. These are all positive tests i.e. compile fine. Thanks, Leonid On 3/15/19 1:20 PM, Alex Buckley wrote: OK, we intend at least one result expression to be required, so the spec is correct as is. (I should have been clearer that my belief was about the intent of the spec, rather than

Re: Switch expressions spec

yielding a value, it would be impossible to infer the type of the expression. On Mar 15, 2019, at 3:01 PM, John Rose wrote: On Mar 15, 2019, at 11:39 AM, Alex Buckley wrote: In a switch expression, I believe it should be legal for every `case`/`default` arm to complete abruptly _for a reason other

Re: Switch expressions spec

// The mail below doesn't appear to have made it to the amber-spec-experts web archive, even though Manoj is a member of the list. Hey Gavin, In a switch expression, I believe it should be legal for every `case`/`default` arm to complete abruptly _for a reason other than a break with value_.

Re: Switch expressions spec

Hi Gavin, On 3/6/2019 1:51 AM, Manoj Palat wrote: *1: In section, *14.15 The breakStatement A breakstatement transfers control out of an enclosing statement_, or causes an enclosing __switch__expression to produce a specified value_. /BreakStatement:/ break[~~ /Identifier/~~];

Re: Switch expressions spec

For clarity, we have renamed the January 2019 version from: http://cr.openjdk.java.net/~gbierman/switch-expressions-old.html to: http://cr.openjdk.java.net/~gbierman/switch-expressions-2019-01.html The CSR for switch expressions (JDK-8207241) has the spec as an attachment, but also links to

Re: Updated document on data classes and sealed types

On 3/1/2019 12:14 PM, Brian Goetz wrote: While the previous version was mostly about tradeoffs, this version takes a much more opinionated interpretation of the feature, offering more examples of use cases of where it is intended to be used (and not used). (Setting aside value records

Re: Hyphenated keywords and switch expressions

Hi Gavin, Some points driven partly by the discussion with Tagir: 1. In 14.11.1, SwitchLabeledBlock should not end with a `;` -- there is no indication in JEP 325 that a semicolon is desired after `-> {...}` and javac in JDK 12 does not accept one there. Also, SwitchLabeledThrowStatement

Re: Hyphenated keywords and switch expressions

Hi Gavin, Some points driven partly by the discussion with Tagir: 1. In 14.11.1, SwitchLabeledBlock should not end with a `;` -- there is no indication in JEP 325 that a semicolon is desired after `-> {...}` and javac in JDK 12 does not accept one there. Also, SwitchLabeledThrowStatement

Re: Hyphenated keywords and switch expressions

Hi Tagir, On 1/13/2019 2:53 AM, Tagir Valeev wrote: Ah, ok, we moved away slightly from the spec draft [1]. I was not aware, because I haven't wrote parser by myself. The draft says: SwitchLabeledRule: SwitchLabeledExpression SwitchLabeledBlock SwitchLabeledThrowStatement

Re: Hyphenated keywords and switch expressions

Hi Tagir, On 1/11/2019 5:32 AM, Tagir Valeev wrote: On the other hand, from IDE developer point of view, having expression and statement with so similar syntax definitely adds a confusion to the parsing (and probably to users). E.g. suppose we want to parse a fragment which consists of a number

Re: New JEP: Concise Method Bodies

On 9/21/2018 4:07 PM, Kevin Bourrillion wrote: "The method reference form can use most kinds of method references after the = sign: static and unbound method references, bound method references (if the receiver *variable* is in scope for the method declaration)" Can we still bind to any

Re: JEP draft: Concise Method Bodies - extend this to local functions?

On 9/20/2018 2:16 PM, Remi Forax wrote: yes, but in your example the return type is not the same, i prefer mine class Utils { Function fun() = this::bar; Function fun2() -> this::bar; Function bar() { return null; } String bar(String s) { return null; } } Yes, it's

Re: JEP draft: Concise Method Bodies - extend this to local functions?

On 9/20/2018 1:28 PM, Maurizio Cimadamore wrote: Function fun() = Utils::bar; Function fun = Utils::bar; (first is method body, second is variable initializer) I think Remi is noting the fact that, when using `->`, the single expression can be a method reference expression. I have already

Re: New JEP: Concise Method Bodies

On 9/20/2018 12:05 PM, Kevin Bourrillion wrote: In this case, I think the `=/` /form /might/ also clear that bar because of the automatic parameter pass-through. But I cannot currently see how the `->` form comes close to clearing it. (Data welcome.) Ooh, you know the magic words! Okay,

New JEP: Concise Method Bodies

https://bugs.openjdk.java.net/browse/JDK-8209434

Re: JEP325: Switch expressions spec

On 5/10/2018 10:36 AM, Dan Smith wrote: On May 10, 2018, at 6:28 AM, Gavin Bierman wrote: 15.29 "the switch expression completes normally": More conventionally, "the value of the switch expression is …" That phrase occurs in several places, so you’ll have to tell me

Re: Raw string literals and Unicode escapes

On 2/14/2018 12:42 PM, John Rose wrote: On Feb 14, 2018, at 12:24 PM, Alex Buckley <alex.buck...@oracle.com <mailto:alex.buck...@oracle.com>> wrote: There is plenty of precedent for semantic rules In my draft version this is done with "where" clauses on the grammar rul

Raw string literals and Unicode escapes

I suspect the trickiest part of specifying raw string literals will be the lexer's modal behavior for Unicode escapes. As such, I am going to put the behavior under the microscope. Here is what the JEP has to say: - Unicode escapes, in the form \u, are processed as part of character

Re: Fix Parameter Runtime*ParameterAnnotations spec

On 10/31/2017 1:47 AM, Remi Forax wrote: Hi all, the spec of the Runtime*ParameterAnnotations attribute [1], allow the number of parameter annotations to be different from the number of parameter from the method descriptor but it fails to provide a way to retrieve/compute the mapping between a