> From: "Archie Cobbs"
> To: "amber-spec-experts"
> Sent: Saturday, June 15, 2024 12:50:13 AM
> Subject: Re: Local classes and static members?
> Answering my own question...
> It's a dumb question because it's no longer true. Originally local classes
> could
> not have static members but that
> From: "Brian Goetz"
> To: "Remi Forax" , "amber-spec-experts"
>
> Sent: Tuesday, April 30, 2024 3:32:35 PM
> Subject: Re: Derived record creation and Data Oriented programming
> Interesting idea. Of the two sides, allowing explicit *constructor*
Hello,
they have been several messages on amber-dev about the compatibility of the
derived record creation.
I think part of the issue reported is that with the proposed syntax, the call
to the desconstructor and the canonical constructor is implicit.
Let's take an example
record Point(int
> From: "Brian Goetz"
> To: "attila kelemen85"
> Cc: "amber-dev" , "Gavin Bierman"
>
> Sent: Tuesday, April 23, 2024 3:34:16 PM
> Subject: Re: New candidate JEP: 468: Derived Record Creation (Preview)
[promoted to amber-spec-expert because I think this discussion is quite
interresting]
> So,
I agree with Tagir here,
a lot of exceptions come from the fact that we do not have pattern methods yet
(Integer.parseInt, etc) and a try expression (try-with-resources expression,
try-catch expression or try-finally expression) seems to compose better than a
"case throws".
regards,
Rémi
> From: "Guy Steele"
> To: "Remi Forax"
> Cc: "Brian Goetz" , "amber-spec-experts"
>
> Sent: Thursday, April 4, 2024 5:04:30 PM
> Subject: Re: Member Patterns -- the bikeshed
>> On Apr 4, 2024, at 9:30 AM, fo...@univ-mlv.fr wro
- Original Message -
> From: "Ron Pressler"
> To: "Remi Forax"
> Cc: "Brian Goetz" , "amber-spec-experts"
>
> Sent: Thursday, April 4, 2024 5:24:01 PM
> Subject: Re: String template interpolation as a two steps process
&g
> From: "Brian Goetz"
> To: "Remi Forax" , "amber-spec-experts"
>
> Sent: Wednesday, April 3, 2024 8:07:42 PM
> Subject: Re: String template interpolation as a two steps process
> We've had this discussion before.
Not exactly, i will try t
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Wednesday, April 3, 2024 5:00:55 PM
> Subject: Re: Member Patterns -- the bikeshed
> Despite several years of warnings and other attempts at preparing the ground,
> y
> From: "Guy Steele"
> To: "Remi Forax"
> Cc: "Brian Goetz" , "amber-spec-experts"
>
> Sent: Wednesday, April 3, 2024 8:46:48 PM
> Subject: Re: Member Patterns -- the bikeshed
> Rémi,
> I get the impression that, in introduci
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Wednesday, April 3, 2024 2:48:40 PM
> Subject: Re: Member Patterns -- the bikeshed
> I would summarize your comments below as: Let's throw the entire model in the
>
Hello,
I would be even more brutal here because I think that the reason *alternative
representation* is better serve by factory methods than constructors.
The same way, in term of de-constructrion, for *alternative representation*, a
named method pattern is better than a deconstructor.
So
Hello,
I think it is also interesting to instead of starting from deconstruction and
then trying to expand, to do in the other way, starts with a pattern backed by
a method and then see the deconstruction as a special case of a pattern backend
by a method. So instead of using a top-down
as an example,
https://github.com/forax/html-component/blob/master/src/test/java/Demo.java
Here is how it works, the idea is that if i want to generate the XML of a
product, i will write something like this.
record Product(String name, int price) implements Component {
public Renderer render
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Monday, March 18, 2024 2:38:34 PM
> Subject: Re: Update on String Templates (JEP 459)
> I think this has been a good discussion, and it looks like we're starting to
> see
> some convergence.
[...]
> A few people have implied that only
> From: "Maurizio Cimadamore"
> To: "Guy Steele"
> Cc: "amber-spec-experts"
> Sent: Friday, March 15, 2024 5:31:28 PM
> Subject: Re: Update on String Templates (JEP 459)
> Hi
> On 15/03/2024 16:07, Guy Steele wrote:
>> Then again, now that I ponder the space of use cases, it may be that,
>>
- Original Message -
> From: "Guy Steele"
> To: "Remi Forax"
> Cc: "Brian Goetz" , "amber-spec-experts"
>
> Sent: Wednesday, March 13, 2024 10:04:46 PM
> Subject: Re: Update on String Templates (JEP 459)
>> On Mar 13, 20
- Original Message -
> From: "Guy Steele"
> To: "John Rose"
> Cc: "Tagir Valeev" , "Brian Goetz"
> , "amber-spec-experts"
>
> Sent: Wednesday, March 13, 2024 9:13:30 PM
> Subject: Re: Update on String Templates (JEP 459)
>> On Mar 13, 2024, at 3:33 PM, John Rose wrote:
>>
>> On 9
Hello,
> Another, simpler, option we consider was to use some kind of prefix to mark a
> string template literal (e.g. make that explicit, instead of resorting to
> language wizardry). That works, but has the disadvantage of breaking the
> spell that there is only “one string literal”, which
choice.
Rémi
> From: "Brian Goetz"
> To: "Remi Forax" , "amber-spec-experts"
>
> Sent: Friday, February 23, 2024 3:49:21 PM
> Subject: Re: module-import declaration
> (I think we've had this discussion already? Seems eerily familiar.)
> I re
Hello,
I've just read the draft of the third version of the implicit class JEP
https://openjdk.org/jeps/8323335
There is a funny paragraph about why there is a need for an import module
syntax.
"""
One theme of this JEP is the elegant evolution of simple programs to proper
declared classes
- Original Message -
> From: "daniel smith"
> To: "amber-spec-experts"
> Sent: Friday, January 26, 2024 10:48:18 PM
> Subject: Re: Field initialization before 'super'
> Having worked through the JLS changes (which I'll be sharing at some point
> soon), here are a few extra details that
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Friday, January 26, 2024 7:11:29 PM
> Subject: Re: Towards member patterns
>>> - We basically agree that at the use site, we have all the qualification
>
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Friday, January 26, 2024 6:30:33 PM
> Subject: Re: Towards member patterns
>>> (It could also be a default pattern; works the same as default meth
> From: "Gavin Bierman"
> To: "Remi Forax"
> Cc: "Brian Goetz" , "amber-spec-experts"
>
> Sent: Friday, January 26, 2024 1:36:22 PM
> Subject: Re: Towards member patterns
> Hi Remi,
>> On 26 Jan 2024, at 11:08, Remi Forax
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Friday, January 26, 2024 1:31:54 PM
> Subject: Re: Towards member patterns
>> I think your proposal solves the cases where the type you are switching on is
>>
Let's retry.
I think your proposal solves the cases where the type you are switching on is
closed (final, sealed) but not if the type is open (non-sealed).
Let's take an example, let suppose I've the following hierarchy
public sealed interface Tree {
static Tree none() { return
> From: "Maurizio Cimadamore"
> To: "Remi Forax" , "Gavin Bierman"
>
> Cc: "amber-spec-experts"
> Sent: Thursday, January 25, 2024 1:41:57 PM
> Subject: Re: Draft JEP: Derived Record Creation (Preview)
> Looking from ano
> From: "Dan Heidinga"
> To: "Remi Forax" , "Brian Goetz"
> Cc: "Gavin Bierman" , "amber-spec-experts"
>
> Sent: Thursday, January 25, 2024 2:56:54 AM
> Subject: Re: Draft JEP: Derived Record Creation (Preview)
> Remi,
> From: "Brian Goetz"
> To: "Remi Forax" , "Gavin Bierman"
>
> Cc: "amber-spec-experts"
> Sent: Wednesday, January 24, 2024 9:33:34 PM
> Subject: Re: Draft JEP: Derived Record Creation (Preview)
>> And as a general remark
Hello Gavin,
nice job, some small remarks.
> "The derived instance creation expression ... is logically equivalent to the
> following switch expression".
This is not stricto-sensu true because the switch expression exhaustiveness
allows remainder. For example, the switch expression allows
Hello,
I agree until the section 'Recovering static factory arguments', because at
that point, it's the tail waging the dog.
In this section you introduce a new syntax with little justification ("it makes
sense") which should not a big problem if it was not your way to justify the
introduction
- Original Message -
> From: "Pavel Rappo"
> To: "core-libs-dev"
> Sent: Tuesday, January 2, 2024 12:56:08 PM
> Subject: Blessed modifier order does not include sealed/non-sealed
> I couldn't find any prior discussions on this matter.
>
> I noticed that bin/blessed-modifier-order.sh
> From: "Archie Cobbs"
> To: "Remi Forax"
> Cc: "daniel smith" , "amber-spec-experts"
>
> Sent: Wednesday, December 13, 2023 5:29:27 PM
> Subject: Re: Field initialization before 'super'
> On Wed, Dec 13, 2023 at 10:02 AM Remi Forax
- Original Message -
> From: "daniel smith"
> To: "amber-spec-experts"
> Sent: Wednesday, December 13, 2023 1:27:24 AM
> Subject: Field initialization before 'super'
> In Valhalla we've been building on the language changes in JEP 447 (Statements
> Before Super) to move towards a more
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Wednesday, December 13, 2023 12:04:09 AM
> Subject: Re: Effect cases in switch
>>> Exception cases can be used in all forms of `switch`: expression and
>>&g
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, December 12, 2023 10:23:09 PM
> Subject: Effect cases in switch
> Based on some inspiration from OCaml, and given that the significant upgrades
> to
> switch so far position it to do a lot more than it could before, we've been
>
> From: "Angelos Bimpoudis"
> To: "amber-spec-experts"
> Cc: "Yuriy Maslyanko"
> Sent: Wednesday, October 25, 2023 12:49:18 AM
> Subject: Fw: JEP 455: Non-enhanced switch statements
> Hello all!
Hello Angelos,
> Yuriy pointed out a valid point.
> 1) Should we treat
- Original Message -
> From: "Tagir Valeev"
> To: "Gavin Bierman"
> Cc: "amber-spec-experts"
> Sent: Tuesday, October 10, 2023 7:33:13 AM
> Subject: Re: Draft Spec for Second Preview of String Templates (JEP 459)
> Hello, experts!
>
> Probably it's possible to fix the small thing I
Hi recently Clément BOUDEREAU has reported a bug on amber-dev and unrelated to
that bug,
taking a look to the code I've noticed this
int compareTo(final Value o) {
return switch (new Tuple<>(this, o)) {
case Tuple, Value>(Value.Infinite _,
Value.Infinite _)
> From: "Angelos Bimpoudis"
> To: "Clément BOUDEREAU" , "Gavin Bierman"
>
> Cc: "Brian Goetz" , "Tagir Valeev"
> ,
> "amber-dev" , "amber-spec-experts"
>
> Sent: Wednesday, September 27, 2023 3:33:26 PM
> Subject: Re: [External] : Re: New candidate JEP: 456: Unnamed Variables and
> Patterns
>
- Original Message -
> From: "Tagir Valeev"
> To: "amber-dev"
> Cc: "Angelos Bimpoudis" , "amber-spec-experts"
>
> Sent: Tuesday, September 26, 2023 2:32:06 PM
> Subject: Re: New candidate JEP: 456: Unnamed Variables and Patterns
> Hello! As we are finalizing this feature, can we
I know that I'm asking a lot, but I believe the way the String template JEP is
written and the API is designed uses the wrong center.
This spec is not about the string template, it's about the template processor,
the string template is just a parameter of the processor.
This was not true
Given this is a spec issue, I think it should be discussed on the spec-experts
list,
> From: "Brian Goetz"
> To: "Bas Leijdekkers" , "amber-dev"
>
> Sent: Friday, September 15, 2023 5:17:53 PM
> Subject: Re: String Templates Expression Statement
> We have gone back and forth on this, but I
- Original Message -
> From: "Tagir Valeev"
> To: "Brian Goetz"
> Cc: "amber-spec-experts"
> Sent: Monday, August 14, 2023 5:28:19 PM
> Subject: Re: [patterns] Several patterns and guards
> I don't think that my example is contrived. Let's think of it from
> another angle. Are multiple
- Original Message -
> From: "Brian Goetz"
> To: "Tagir Valeev"
> Cc: "amber-spec-experts"
> Sent: Monday, August 14, 2023 5:04:19 PM
> Subject: Re: [patterns] Several patterns and guards
> While we could certainly do this, I think the cost-benefit runs in the wrong
> direction here.
- Original Message -
> From: "Tagir Valeev"
> To: "amber-spec-experts"
> Sent: Thursday, August 3, 2023 1:51:55 PM
> Subject: Re: [Correction] Re: [string-templates] Covariant signature of
> 'process' method
Hi Tagir,
> Additional thoughts on this topic.
>
> 1. Currently, it looks
- Original Message -
> From: "Alex Buckley"
> To: "amber-spec-experts"
> Sent: Tuesday, July 25, 2023 5:51:39 PM
> Subject: Re: [string-templates] Template expression in expression statement?
> On 7/25/2023 2:07 AM, Remi Forax wrote:
>>
Currently javac uses a trick to rewrite STR."" template to more or less the
string concatenation equivalent, by passing the call to the bootstrap method of
the string template runtime.
But this rewriting
- has a side effect at runtime, the class StringTemplate is not loaded.
- exact behavior
- Original Message -
> From: "Tagir Valeev"
> To: "amber-spec-experts"
> Sent: Tuesday, July 25, 2023 10:52:04 AM
> Subject: [string-templates] Template expression in expression statement?
> Hello!
>
> It looks like, the latest javac (build 22-ea+7-489) accepts string
> templates as
- Original Message -
> From: "Jim Laskey"
> To: "Maurizio Cimadamore"
> Cc: "Tagir Valeev" , "amber-spec-experts"
> , "amber-spec-experts"
>
> Sent: Thursday, July 20, 2023 11:34:04 AM
> Subject: Re: Native methods in unnamed classes
> I think we will be moving toward stabilizing the
Hello,
currently, it's not possible to write a lot of generics sealed type because
Java has no way to denote the bottom type.
By example, if a Result can be either a Success or an Error, we want to be able
to write this kind of switch
public static void main(String[] args) {
Result
Hi all,
thinking a little bit about STR and FMT, I wonder if we should not introduce
also two other template processors, IN and OUT.
IN is the input template processor, it asks a user for a string on the standard
input
String name = IN."what is your name ?";
It works like input (raw_input)
- 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 "cas
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)."
> From: "Remi Forax"
> To: "Brian Goetz"
> Cc: "amber-spec-experts"
> Sent: Monday, April 17, 2023 5:16:25 PM
> Subject: Re: String templates and constant expressions
>> From: "Brian Goetz"
>> To: "amber-spec-expe
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Monday, April 17, 2023 4:05:18 PM
> Subject: Fwd: String templates and constant expressions
> This was received on the -comments list. It raises a question which I realize
> now was not explicitly discussed with the EG, but which was
- Original Message -
> From: "Tagir Valeev"
> To: "Remi Forax"
> Cc: "Guy Steele" , "Brian Goetz"
> , "amber-spec-experts"
>
> Sent: Saturday, April 15, 2023 9:48:14 AM
> Subject: Re: Revisit the String templa
- Original Message -
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Wednesday, April 12, 2023 6:21:38 PM
> Subject: Re: Revisit the String template syntax
> The backslash syntax is objectively better t
- Original Message -
> From: "Guy Steele"
> To: "Brian Goetz"
> Cc: "Remi Forax" , "amber-spec-experts"
>
> Sent: Wednesday, April 12, 2023 6:38:13 PM
> Subject: Re: Revisit the String template syntax
>> On Apr 12, 20
> From: "Robbe Pincket"
> To: "amber-dev"
> Sent: Monday, April 10, 2023 1:27:22 PM
> Subject: Named record patterns
> Hi all
> I was wondering if named record patterns `o instanceof Pair(String left,
> String
> right) pair` are still on the table for the future or not. (Not sure if
>
I've promoted this email to amber-spec-experts given that several people on the
internet and offline have said more or less the same thing.
Even if it's not for 21, now that a string template is always prefixed by a
template processor, the part in between quote does not need to rely on
+1 from me.
It makes the spec less intimidating for users.
Rémi
> From: "Jim Laskey"
> To: "amber-spec-experts"
> Sent: Monday, March 27, 2023 3:07:12 PM
> Subject: Re: StringTemplates name changes
> After the string template interface name changes, i.e., TemplateProcessor
> becoming
- Original Message -
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Saturday, March 11, 2023 4:52:50 PM
> Subject: Re: Deconstruction patterns
> I agree that translating dtors as static methods is pr
I've coded a possible implementation here
https://github.com/forax/amber-deconstructor
- instead of mangling the name, i've followed literally what Dan H said, the VM
is good to find a method from a method name and a *descriptor*, so like when
you want to have two overloads of a constructor
- Original Message -
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Wednesday, March 8, 2023 5:35:37 PM
> Subject: Re: Deconstructor can not be overriden ? Was: Deconstruction patterns
>> The duality y
- Original Message -
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Tuesday, March 7, 2023 9:48:11 PM
> Subject: Re: Deconstructor can not be overriden ? Was: Deconstruction patterns
>>> Again, I canno
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Tuesday, March 7, 2023 8:34:02 PM
> Subject: Re: Overloading of matcher method Was: Deconstruction patterns
> Remi pointed out privately that I didn't answer this
- Original Message -
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Tuesday, March 7, 2023 8:42:37 PM
> Subject: Re: Deconstructor can not be overriden ? Was: Deconstruction patterns
>>> No, it is
- Original Message -
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Tuesday, March 7, 2023 7:02:56 PM
> Subject: Re: Deconstructor can not be overriden ? Was: Deconstruction patterns
>> Conceptually t
- Original Message -
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Tuesday, March 7, 2023 3:31:26 PM
> Subject: Re: Deconstructor can not be overriden ? Was: Deconstruction patterns
>> Why deconstr
The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.
--
> From: "Dan Heidinga"
> To: &q
- Original Message -
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Monday, March 6, 2023 7:24:54 PM
> Subject: Deconstruction patterns
> Time to look ahead to the next installment of pattern matching:
> deconstruction patterns, which generalize record patterns. This
>
- Original Message -
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Monday, March 6, 2023 7:24:54 PM
> Subject: Deconstruction patterns
> Time to look ahead to the next installment of pattern matching:
> deconstruction patterns, which generalize record patterns. This
>
- Original Message -
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Monday, March 6, 2023 7:24:54 PM
> Subject: Deconstruction patterns
> Time to look ahead to the next installment of pattern matching:
> deconstruction patterns, which generalize record patterns. This
>
- Original Message -
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Monday, March 6, 2023 7:24:54 PM
> Subject: Deconstruction patterns
> Time to look ahead to the next installment of pattern matching:
> deconstruction patterns, which generalize record patterns. This
>
- Original Message -
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Monday, March 6, 2023 7:24:54 PM
> Subject: Deconstruction patterns
> Time to look ahead to the next installment of pattern matching:
> deconstruction patterns, which generalize record patterns. This
>
- Original Message -
> From: "John Hendrikx"
> To: "Gavin Bierman" , "amber-dev"
>
> Cc: "amber-spec-experts"
> Sent: Tuesday, February 28, 2023 10:11:39 PM
> Subject: Re: Draft JEPs for Patterns in switch and Record Patterns
> In https://openjdk.org/jeps/8300542, the example in
- Original Message -
> From: "Gavin Bierman"
> To: "amber-dev"
> Cc: "amber-spec-experts"
> Sent: Tuesday, February 28, 2023 5:21:42 PM
> Subject: Draft JEPs for Patterns in switch and Record Patterns
> Hello,
>
> We are planning to finalize the two pattern matching JEPs in JDK 21.
> From: "Maurizio Cimadamore"
> To: "Angelos Bimpoudis" , "Brian Goetz"
> , "amber-spec-experts"
>
> Sent: Thursday, February 23, 2023 7:26:11 PM
> Subject: Re: Draft JLS Spec about unnamed patterns and variables
>> Under this JEP this code could be rewritten blindly into:
>> switch (o) {
>>
> From: "Brian Goetz"
> To: "Tagir Valeev" , "Angelos Bimpoudis"
>
> Cc: "amber-spec-experts"
> Sent: Wednesday, February 22, 2023 4:45:38 PM
> Subject: Re: Draft JLS Spec about unnamed patterns and variables
> It's a tricky question, because there's lots of ways to come at it. For
> example,
> From: "Dan Heidinga"
> To: "Remi Forax"
> Cc: "Brian Goetz" , "Ron Pressler"
> , "amber-spec-experts"
>
> Sent: Tuesday, February 21, 2023 2:59:59 PM
> Subject: Re: Implicit Record Was: JEP draft: Implicit Classes and
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "Ron Pressler" , "Dan Heidinga"
> , "amber-spec-experts"
> Sent: Tuesday, February 21, 2023 12:33:31 AM
> Subject: Re: Implicit Record Was: JEP draft: Implicit Classes and Enh
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "Ron Pressler" , "Dan Heidinga"
> , "amber-spec-experts"
> Sent: Monday, February 20, 2023 9:33:34 PM
> Subject: Re: Implicit Record Was: JEP draft: Implicit Classes and Enhanced
> From: "Brian Goetz"
> To: "Remi Forax" , "Ron Pressler"
> Cc: "Dan Heidinga" , "amber-spec-experts"
>
> Sent: Monday, February 20, 2023 7:57:53 PM
> Subject: Re: Implicit Record Was: JEP draft: Implicit Classes and Enhanced
> From: "Ron Pressler"
> To: "Remi Forax"
> Cc: "Dan Heidinga" , "Brian Goetz"
> , "amber-spec-experts"
>
> Sent: Monday, February 20, 2023 10:47:57 AM
> Subject: Re: Implicit Record Was: JEP draft: Implicit Classes and Enh
> From: "Dan Heidinga"
> To: "Ron Pressler"
> Cc: "Remi Forax" , "amber-spec-experts"
>
> Sent: Friday, February 17, 2023 5:56:49 PM
> Subject: Re: [External] : Re: JEP draft: Implicit Classes and Enhanced Main
> Metho
> From: "Ron Pressler"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Thursday, February 16, 2023 12:52:24 AM
> Subject: Re: [External] : Re: JEP draft: Implicit Classes and Enhanced Main
> Methods (Preview)
>> On 15 Feb 2023, at
> From: "Ron Pressler"
> To: "amber-spec-experts"
> Sent: Wednesday, February 15, 2023 5:14:21 PM
> Subject: JEP draft: Implicit Classes and Enhanced Main Methods (Preview)
> Hi.
> I've published a JEP draft, Implicit Classes and Enhanced Main Methods
> (Preview)
> ( [
> From: "Guy Steele"
> To: "Brian Goetz"
> Cc: "Remi Forax" , "Angelos Bimpoudis"
> , "amber-spec-experts"
>
> Sent: Thursday, January 26, 2023 4:25:16 PM
> Subject: Re: Draft JEP on Primitive types in patter
> From: "Brian Goetz"
> To: "Remi Forax" , "Angelos Bimpoudis"
>
> Cc: "amber-spec-experts"
> Sent: Thursday, January 26, 2023 3:36:22 PM
> Subject: Re: Draft JEP on Primitive types in patterns, instanceof, and switch
> Everyt
> From: "Angelos Bimpoudis"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Thursday, January 26, 2023 2:55:31 PM
> Subject: Re: Draft JEP on Primitive types in patterns, instanceof, and switch
> Thanks for the quick reply.
> I t
> From: "Angelos Bimpoudis"
> To: "amber-spec-experts"
> Sent: Thursday, January 26, 2023 11:36:53 AM
> Subject: Draft JLS Spec about unnamed patterns and variables
> Dear experts,
> The first draft of the JLS spec about unnamed patterns and variables
> (https://openjdk.org/jeps/8294349) is
> From: "Angelos Bimpoudis"
> To: "amber-dev"
> Sent: Thursday, January 26, 2023 10:48:47 AM
> Subject: Draft JEP on Primitive types in patterns, instanceof, and switch
> Hello all,
> I would like to share this draft JEP with you about primitive types in
> patterns,
> instanceof, and switch:
- Original Message -
> From: "Brian Goetz"
> To: "Tagir Valeev"
> Cc: "amber-spec-experts"
> Sent: Monday, November 28, 2022 9:05:51 PM
> Subject: Re: Make 'package' and 'import' contextual keywords
> I would not have predicted this coming from an IDE developer, so this is quite
>
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "John Rose" , "Alex Buckley"
> , "amber-spec-experts"
>
> Sent: Tuesday, November 15, 2022 12:35:24 AM
> Subject: Re: Late change to JEP 433
> I win my bet! I had my mo
> From: "Brian Goetz"
> To: "Remi Forax" , "John Rose"
> Cc: "Alex Buckley" , "amber-spec-experts"
>
> Sent: Monday, November 14, 2022 11:40:27 PM
> Subject: Re: Late change to JEP 433
> Its MatchException. Error woul
> From: "Archie Cobbs"
> To: "Nathan Reynolds"
> Cc: "Brian Goetz" , "John Hendrikx" ,
> "Remi Forax" , "amber-dev" ,
> "amber-spec-experts" , "Ron Pressler"
>
> Sent: Monday, November 14, 2022
> From: "John Hendrikx"
> To: "Remi Forax" , "Nathan Reynolds"
>
> Cc: "amber-dev" , "amber-spec-experts"
> , "Ron Pressler"
>
> Sent: Saturday, November 12, 2022 5:16:10 PM
> Subject: Re: Retiring Checked
I'm confused, is it MatchError or MatchException ?
Because if it's an error instead of an exception, it may be less an issue in
term of backward compatibility but it is not what is proposed, right ?
Rémi
- Original Message -
> From: "John Rose"
> To: "Alex Buckley"
> Cc:
1 - 100 of 145 matches
Mail list logo
