From davidalayachew at gmail.com Tue Mar 4 13:03:55 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 4 Mar 2025 08:03:55 -0500 Subject: Question about IO.println Message-ID: Hello Amber Dev Team and Core Libs Dev Team, Another reddit discussion popped up today about IO.println(), and one of the comments mentioned that they wanted something along the lines of this. IO.println(num1, num2, num3); //prints out "1 2 3" I proposed that maybe a better option would be a String.join overload. So, instead of String.join(String delim, String... elements), there would be String.join(String delim, Object... elements), with each object getting toString() called on it. What are your thoughts on either of these ideas? I actually think the IO.println() version is nice, but I felt like String.join made a slightly better compromise. Another commentor mentioned that this will be easier with String Templates too, so maybe it is better to wait for that. I don't think String templates are a bad idea here, but it also felt like overkill imo. A library function seems like a better fit. Thank you for your time and thoughts. David Alayachew -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Tue Mar 4 13:13:10 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 4 Mar 2025 08:13:10 -0500 Subject: Question about IO.println In-Reply-To: References: Message-ID: Sorry, forgot to link the thread. https://old.reddit.com/r/java/comments/1j2pr78/ And here is the comment in question. https://old.reddit.com/r/java/comments/1j2pr78/compact_source_files_and_instance_main_methods_jep/mfy9dof/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From newblood17 at gmail.com Tue Mar 4 02:14:10 2025 From: newblood17 at gmail.com (mirage) Date: Mon, 3 Mar 2025 21:14:10 -0500 Subject: Possible future implicit import of static methods Message-ID: The new features for compact source files and instance main methods are about to make their GA debut in JDK 25: https://openjdk.org/jeps/8344699 I want to extend my gratitude to all the Java team developers. I?m not a formal teacher, but I?ve done some minor instructing for students interning at one of the companies I used to work for. These and other JEPs?such as import modules and the implicit import of Java.base?certainly bring Java closer to what new programmers are used to (e.g., Python and JavaScript). They also allow Java to be more function/method-focused by removing the need to declare classes when they?re not required, which I personally believe is a positive direction. I hope Java continues to explore more of this in the future, but this is just a personal thought. Regarding the decision not to implicitly import static methods inside java.io, I know some see this as a misstep. I?ve been following the mailing discussions about ?dot notation? closely, and I personally think maintaining language consistency is preferable to introducing special-case features that only work under certain conditions (such as implicit static imports of java.io for compact source files only). Still, I believe it would be worth considering?perhaps in a future JEP?the implicit import of some of the most commonly used static methods in java.lang (maybe including IO, Math, and utility methods in wrapper classes), not just for compact source files but for all file types. I?ve always found it odd to limit such improvements to ?classless main files? or files with an implicit class declaration. Many utility methods in java.lang are so fundamental and universally used that it?s unlikely anyone would bring in a third-party library just to parse a string to a numeric value or vice versa. Therefore, the rationale for requiring explicit class declarations (to identify the source of these methods and distinguish between similarly named methods in different classes) doesn?t seem very compelling in these basic cases. Removing the implicit static import from this JEP leaves the door open for a future JEP to go further. I realize the main challenge is deciding which static methods deserve this special treatment (and there will always be people advocating for their personal favorites). However, these methods could be introduced gradually, and the implicit import wouldn?t break source compatibility. Is there any chance we might see something like this in the future? - Always yours. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Tue Mar 4 14:16:39 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 4 Mar 2025 09:16:39 -0500 Subject: Possible future implicit import of static methods In-Reply-To: References: Message-ID: The question of automatically statically importing certain "important" methods was a fraught one, and the more we investigated it, the more we regretted opening this particular Pandora's Box. The reality is that any method that is static-imported by the language, effectively is elevated to a "language feature", just one with a regularized syntax.? And this is a pretty high bar.? We started with `println`, which almost everyone thought "obviously" was important enough to be important enough to clear that bar. But once we started investigating, the "next most important" method could barely jump 10% as high as println did, and it went downhill from there.? Indeed, it seems we were mostly trying to extrapolate from a single example. As part of the exploration, we looked at the set of "built in" functions in other languages, such as Python, and asked ourselves: "would we be proud of this set of built-in functions."? And the answer was that it was really kind of an accidental grab bag, and we surely didn't want that -- and we couldn't imagine how we wouldn't end up with that. The inevitable bikeshedding of "please elevate my favorite method" would indeed be a ongoing, contentious-at-times, expensive process.? But that's not even the worst part -- we would surely end up with yet another accidental grab bag, which does not help users form a coherent mental model of these specially-treated functions. So we are actually feeling quite good about the conclusion of "nothing is auto-static-imported". On 3/3/2025 9:14 PM, mirage wrote: > > Still, I believe it would be worth considering?perhaps in a future > JEP?the implicit import of some of the most commonly used static > methods in java.lang (maybe including IO, Math, and utility methods in > wrapper classes), not just for compact source files but for all file > types. I?ve always found it odd to limit such improvements to > ?classless main files? or files with an implicit class declaration. > Many utility methods in java.lang are so fundamental and universally > used that it?s unlikely anyone would bring in a third-party library > just to parse a string to a numeric value or vice versa. Therefore, > the rationale for requiring explicit class declarations (to identify > the source of these methods and distinguish between similarly named > methods in different classes) doesn?t seem very compelling in these > basic cases. Removing the implicit static import from this JEP leaves > the door open for a future JEP to go further. > > I realize the main challenge is deciding which static methods deserve > this special treatment (and there will always be people advocating for > their personal favorites). However, these methods could be introduced > gradually, and the implicit import wouldn?t break source compatibility. -------------- next part -------------- An HTML attachment was scrubbed... URL: From newblood17 at gmail.com Tue Mar 4 14:39:23 2025 From: newblood17 at gmail.com (mirage) Date: Tue, 4 Mar 2025 09:39:23 -0500 Subject: Possible future implicit import of static methods In-Reply-To: References: Message-ID: It's fair. Thank you for the explanation. My best wishes for you and all other developers working on the evolution of the Java platform. El mar, 4 de mar de 2025, 9:16?a. m., Brian Goetz escribi?: > The question of automatically statically importing certain "important" > methods was a fraught one, and the more we investigated it, the more we > regretted opening this particular Pandora's Box. > > The reality is that any method that is static-imported by the language, > effectively is elevated to a "language feature", just one with a > regularized syntax. And this is a pretty high bar. We started with > `println`, which almost everyone thought "obviously" was important enough > to be important enough to clear that bar. But once we started > investigating, the "next most important" method could barely jump 10% as > high as println did, and it went downhill from there. Indeed, it seems we > were mostly trying to extrapolate from a single example. > > As part of the exploration, we looked at the set of "built in" functions > in other languages, such as Python, and asked ourselves: "would we be proud > of this set of built-in functions." And the answer was that it was really > kind of an accidental grab bag, and we surely didn't want that -- and we > couldn't imagine how we wouldn't end up with that. > > The inevitable bikeshedding of "please elevate my favorite method" would > indeed be a ongoing, contentious-at-times, expensive process. But that's > not even the worst part -- we would surely end up with yet another > accidental grab bag, which does not help users form a coherent mental model > of these specially-treated functions. > > So we are actually feeling quite good about the conclusion of "nothing is > auto-static-imported". > > > > > > On 3/3/2025 9:14 PM, mirage wrote: > > > Still, I believe it would be worth considering?perhaps in a future JEP?the > implicit import of some of the most commonly used static methods in > java.lang (maybe including IO, Math, and utility methods in wrapper > classes), not just for compact source files but for all file types. I?ve > always found it odd to limit such improvements to ?classless main files? or > files with an implicit class declaration. Many utility methods in java.lang > are so fundamental and universally used that it?s unlikely anyone would > bring in a third-party library just to parse a string to a numeric value or > vice versa. Therefore, the rationale for requiring explicit class > declarations (to identify the source of these methods and distinguish > between similarly named methods in different classes) doesn?t seem very > compelling in these basic cases. Removing the implicit static import from > this JEP leaves the door open for a future JEP to go further. > > I realize the main challenge is deciding which static methods deserve this > special treatment (and there will always be people advocating for their > personal favorites). However, these methods could be introduced gradually, > and the implicit import wouldn?t break source compatibility. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Thu Mar 6 19:32:00 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 6 Mar 2025 20:32:00 +0100 Subject: Suggestion: A wiki page for all answered "Why don't you ...?" In-Reply-To: References: <033d2a24-3c6c-45f0-ac53-8bcb317322a5@oracle.com> Message-ID: On 2025-01-19 18:24, Ethan McCue wrote: > Following up to say: this will take more effort than I thought it > would. New years turned out to be a smidge optimistic. You don't say? :-D I think this is the reason that it has not been done already -- it requires a lot of work. It might be easier to start with something very simple, kind of MVP of a wiki page, just listing some bullet points of ideas and links to the email thread. Like what Archie suggested but even more simple. If this is available where everyone can contribute, hopefully it will be easier to crowdsource incremental improvements, than trying to write a complete, perfect document from scratch. /Magnus > > On Fri, Dec 20, 2024, 9:26?AM Magnus Ihse Bursie > wrote: > > On 2024-12-13 04:02, Ethan McCue wrote: > >> One practical trouble in assembling this is that the mailing >> lists aren't exactly indexed/searchable. > > Yes, that is indeed annoying. :-( > > To be able to search locally on your own computer, you can > download the archives using something like this: > > wget -l 0? --mirror --convert-links --no-parent > https://mail.openjdk.org/pipermail/amber-dev/ > > This will give you all the mails as a -.txt file. > > Our CDN seems to be throttling wget, so you might have do to add > something like > "--user-agent=work-around-missing-searchable-archive" to the > command line... > >> I'll make it my project to put something together by new years >> though. > > That's great to hear. Thank you Ethan! > > /Magnus > >> >> On Fri, Dec 13, 2024, 6:26 AM Louis Wasserman >> wrote: >> >> Just seeing that it hasn't been mentioned, Guava's Idea >> Graveyard is an example of this specific flavor of thing: >> https://github.com/google/guava/wiki/IdeaGraveyard. (It's >> pretty old, though, which reflects some of the downsides.) >> >> On Thu, Dec 12, 2024 at 10:34?AM Archie Cobbs >> wrote: >> >> On Thu, Dec 12, 2024 at 10:07?AM Brian Goetz >> wrote: >> >> There is the amber-docs repo which gets published to >> `openjdk.org/projects/amber` >> , which is >> probably a better place to put it, and people can >> contribute via PRs. >> >> >> I think putting something online under amber-docs is a >> great idea - especially the part where people can >> contribute using PR's, which fosters decentralized >> collaboration on the maintenance of the list. >> >> While it would be ideal to have a complete directory of >> ideas with accompanying summaries of all that has been >> discussed, we should probably start with something >> simpler and more maintainable. >> >> Here's a proposal: Have a list of "previously discussed >> ideas". Each idea has a one line description, a one >> paragraph summary, an optional example, and a >> bullet-point list of one or more links to the thread(s) >> in the archive that contain all the gory details of the >> discussion. >> >> Here's a simple example... >> >> *Idea:* Using switch statements for if/else control flow >> >> *Description:* Support "switches on nothing" where the >> cases simply provide the conditions on which to execute >> various code branches. >> >> *Example:* >> >> ??? public double toInches(String value) { >> switch { >> ??????? case when value.endsWith("mm") -> return >> 0.0393701 * Integer.parseInt(value.substring(0, >> value.length() - 2)); >> ??????? case when value.endsWith("ft") -> return 12 * >> Integer.parseInt(value.substring(0, value.length() - 2)); >> ??????? case when value.endsWith("light-years") ->?return >> 3.725e+17 * Integer.parseInt(value.substring(0, >> value.length() - 2)); >> ??????? default -> throw new >> IllegalArgumentException("can't parse value"); >> ??????? } >> ??? } >> >> *Discussion:* >> >> * https://mail.openjdk.org/pipermail/amber-dev/2024-October/008939.html >> >> >> Just now seeing Eirik's reference to Project Jigsaw's >> Issue Summary document. I like this even better but >> someone would have to step up and take ownership. >> >> -Archie >> >> -- >> Archie L. Cobbs >> >> >> >> -- >> Louis Wasserman (he/they) >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at mccue.dev Thu Mar 6 20:32:00 2025 From: ethan at mccue.dev (Ethan McCue) Date: Thu, 6 Mar 2025 15:32:00 -0500 Subject: Suggestion: A wiki page for all answered "Why don't you ...?" In-Reply-To: References: <033d2a24-3c6c-45f0-ac53-8bcb317322a5@oracle.com> Message-ID: It's almost something you'd want dedicated tooling for - I'm suspicious that there might be OSINT tooling for "stitching together narratives from discussion threads" that already exists. On Thu, Mar 6, 2025, 2:32?PM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2025-01-19 18:24, Ethan McCue wrote: > > Following up to say: this will take more effort than I thought it would. > New years turned out to be a smidge optimistic. > > You don't say? :-D > > I think this is the reason that it has not been done already -- it > requires a lot of work. It might be easier to start with something very > simple, kind of MVP of a wiki page, just listing some bullet points of > ideas and links to the email thread. Like what Archie suggested but even > more simple. If this is available where everyone can contribute, hopefully > it will be easier to crowdsource incremental improvements, than trying to > write a complete, perfect document from scratch. > > /Magnus > > > > On Fri, Dec 20, 2024, 9:26?AM Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> On 2024-12-13 04:02, Ethan McCue wrote: >> >> One practical trouble in assembling this is that the mailing lists aren't >> exactly indexed/searchable. >> >> Yes, that is indeed annoying. :-( >> >> To be able to search locally on your own computer, you can download the >> archives using something like this: >> >> wget -l 0 --mirror --convert-links --no-parent >> https://mail.openjdk.org/pipermail/amber-dev/ >> >> This will give you all the mails as a -.txt file. >> >> Our CDN seems to be throttling wget, so you might have do to add >> something like "--user-agent=work-around-missing-searchable-archive" to the >> command line... >> >> I'll make it my project to put something together by new years though. >> >> That's great to hear. Thank you Ethan! >> >> /Magnus >> >> >> On Fri, Dec 13, 2024, 6:26 AM Louis Wasserman >> wrote: >> >>> Just seeing that it hasn't been mentioned, Guava's Idea Graveyard is an >>> example of this specific flavor of thing: >>> https://github.com/google/guava/wiki/IdeaGraveyard. (It's pretty old, >>> though, which reflects some of the downsides.) >>> >>> On Thu, Dec 12, 2024 at 10:34?AM Archie Cobbs >>> wrote: >>> >>>> On Thu, Dec 12, 2024 at 10:07?AM Brian Goetz >>>> wrote: >>>> >>>>> There is the amber-docs repo which gets published to ` >>>>> openjdk.org/projects/amber` , >>>>> which is probably a better place to put it, and people can contribute via >>>>> PRs. >>>>> >>>> >>>> I think putting something online under amber-docs is a great idea - >>>> especially the part where people can contribute using PR's, which fosters >>>> decentralized collaboration on the maintenance of the list. >>>> >>>> While it would be ideal to have a complete directory of ideas with >>>> accompanying summaries of all that has been discussed, we should probably >>>> start with something simpler and more maintainable. >>>> >>>> Here's a proposal: Have a list of "previously discussed ideas". Each >>>> idea has a one line description, a one paragraph summary, an optional >>>> example, and a bullet-point list of one or more links to the thread(s) in >>>> the archive that contain all the gory details of the discussion. >>>> >>>> Here's a simple example... >>>> >>>> *Idea:* Using switch statements for if/else control flow >>>> >>>> *Description:* Support "switches on nothing" where the cases simply >>>> provide the conditions on which to execute various code branches. >>>> >>>> *Example:* >>>> >>>> public double toInches(String value) { >>>> switch { >>>> case when value.endsWith("mm") -> return 0.0393701 * >>>> Integer.parseInt(value.substring(0, value.length() - 2)); >>>> case when value.endsWith("ft") -> return 12 * >>>> Integer.parseInt(value.substring(0, value.length() - 2)); >>>> case when value.endsWith("light-years") -> return 3.725e+17 * >>>> Integer.parseInt(value.substring(0, value.length() - 2)); >>>> default -> throw new IllegalArgumentException("can't parse >>>> value"); >>>> } >>>> } >>>> >>>> *Discussion:* >>>> >>>> - >>>> https://mail.openjdk.org/pipermail/amber-dev/2024-October/008939.html >>>> >>>> >>>> Just now seeing Eirik's reference to Project Jigsaw's Issue Summary >>>> document. I like this even better but someone would have to step up and >>>> take ownership. >>>> >>>> -Archie >>>> >>>> -- >>>> Archie L. Cobbs >>>> >>> >>> >>> -- >>> Louis Wasserman (he/they) >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Fri Mar 7 11:40:25 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 7 Mar 2025 12:40:25 +0100 Subject: Suggestion: A wiki page for all answered "Why don't you ...?" In-Reply-To: References: <033d2a24-3c6c-45f0-ac53-8bcb317322a5@oracle.com> Message-ID: <47ea447f-6cdc-40d7-b415-da1047477db7@oracle.com> On 2025-03-06 21:32, Ethan McCue wrote: > It's almost something you'd want dedicated tooling for - I'm > suspicious that there might be OSINT tooling for "stitching together > narratives from discussion threads" that already exists. Or maybe throw the entire mailing list archive into an LLM and ask it to summarize? :-D /Magnus From ethan at mccue.dev Fri Mar 7 14:58:13 2025 From: ethan at mccue.dev (Ethan McCue) Date: Fri, 7 Mar 2025 09:58:13 -0500 Subject: Suggestion: A wiki page for all answered "Why don't you ...?" In-Reply-To: <47ea447f-6cdc-40d7-b415-da1047477db7@oracle.com> References: <033d2a24-3c6c-45f0-ac53-8bcb317322a5@oracle.com> <47ea447f-6cdc-40d7-b415-da1047477db7@oracle.com> Message-ID: No On Fri, Mar 7, 2025, 6:41?AM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2025-03-06 21:32, Ethan McCue wrote: > > It's almost something you'd want dedicated tooling for - I'm > > suspicious that there might be OSINT tooling for "stitching together > > narratives from discussion threads" that already exists. > > Or maybe throw the entire mailing list archive into an LLM and ask it to > summarize? :-D > > /Magnus > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Fri Mar 7 21:14:40 2025 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 7 Mar 2025 13:14:40 -0800 Subject: Question about IO.println In-Reply-To: References: Message-ID: Hi, Our goal with the IO class is to have it add as few mechanisms as possible. Anything it can do, one should easily be able to do with existing classes like PrintStream or BufferedReader. So, we wouldn't add a varargs method to IO itself without having one in PrintStream or something. Now, should PrintStream have a varargs overload of println? Well, println first appeared in JDK 1.0 well before varargs existed and the answer then was to use the + string concatenation operator for multiple values. This still works, though there are cases where it doesn't work very well. When varargs was added (5.0) PrintStream got printf with varargs, but println wasn't retrofitted with varargs. And there will be string templates, which will allow one to embed multiple values unobtrusively, so there's no need for varargs here. And a string templates should be directly usable from IO.println, so it'll come for "free". Thus I don't see a need to add varargs overloads here. s'marks On 3/4/25 5:03 AM, David Alayachew wrote: > Hello Amber Dev Team and Core Libs Dev Team, > > Another reddit discussion popped up today about IO.println(), and one of the > comments mentioned that they wanted something along the lines of this. > > IO.println(num1, num2, num3); //prints out "1 2 3" > > I proposed that maybe a better option would be a String.join overload. So, instead > of String.join(String delim, String... elements), there would be String.join(String > delim, Object... elements), with each object getting toString() called on it. > > What are your thoughts on either of these ideas? I actually think the IO.println() > version is nice, but I felt like String.join made a slightly better compromise. > > Another commentor mentioned that this will be easier with String Templates too, so > maybe it is better to wait for that. I don't think String templates are a bad idea > here, but it also felt like overkill imo. A library function seems like a better fit. > > Thank you for your time and thoughts. > David Alayachew From david.1993grajales at gmail.com Tue Mar 11 14:48:31 2025 From: david.1993grajales at gmail.com (david Grajales) Date: Tue, 11 Mar 2025 09:48:31 -0500 Subject: About the possibility of using JEP468 to inspire optional fields in records for domain contracts modeling. Message-ID: Hi Amber team. I would like to share some thoughts based on real use cases I am dealing with at work. I know is very likely you have already thought about something like this and I don't know if this would be the best solution for the use case presented. My intention is not to propose this as "the solution" but instead just present a personal use-case based on my actual job and a naive solution that crossed my mind in the first 15 minutes. So please pay more attention to the use case and "the problem" rather than the proposed "solution" which is actually just a mean to explain the problem Nowadays to create a new record object we must set the value to all it fields, even the ones that might be null. record User (String name, String email){} var userWithoutEmail = new User ("name", null) This is good since it forces us to set all fields to a valid state and null can be a valid state. This is useful for things like JSON serialization; null fields in JSON are usually not serialized, which saves some bandwidth, in very large JSON structures that only have an small set of mandatory fields, this is very common in banks that happens to be international, since they usually use the same Core for all countries but each country may have different requirements (for example in some countries it's mandatory for people to provide 2 lastnames but in other countries usually you only have one lastname). To achieve this I usually do the opposite of withers, let me introduce you to the "withouts" record User (String name, String email){ public static withoutEmail(String name){ return new User(name, null); } } var userWithoutEmail = User.withoutEmail(name); The example is very basic for explanatory purposes and for a record with only 2 fields this can be an overkill, but for bigger records it makes a lot of sense, specially if only few fields between dozens are actually mandatory. Why not use a class instead? Serialization. records' serialization uses the record constructor, which means it's safer since you can make format and safety validations in the data before the record is built. nowadays to make sure all the mandatory fields are set, I do something like this. record User (String name, String email){ User{ if(name == null) throw new IllegalArgumentException("name field it's mandatory"); } } With derived record creation (or something equivalent but for direct creation) and nullability it would be possible and very handy to be able to declare optional fields that would compile to null (or zero in case of primitives) *Please ignore the straw man syntax from here.* record User (String name!, String email? ){} User userWithoutEmail with { name : "name"} This would make this feature in java to behave similar to TypeScript's interfaces, which are used to model data export interface User { name: String! email: String? } To me one of the most useful use cases of this would be for writing unitary tests and mocks. when writing tests sometimes you want to test the behaviour of your contracts (the domain objects) when they carry only the bare required fields, if one has very large json objects to try out but only a small set of mandatory fields usually it's easier to write down the json string and pass it to jackson or gson, with this we could use the domain object directly. Regular test if the domain object has many optional fields record Message (String id, String document, String name, String lastname, String email.... (another 20 fields)){} var request = """{ id: "XXXXXXX", document: "NNN-NNNNN" }""" var message = gson.fromJson(request, Message.class); var res = method2Test(message); // put your favorite assertion here// this has the issue you don't have help from the compiler in case you want to represent different scenarios (formatting data, invalid fields, etc) this is why I usually do "whitouts" for this kind of records. record Message (String id, String document, String name, String lastname, String email.... (another 20 fields)){ public Static Message minimalRequest(String id, String document){ return new Message (id, document, lastname, email, null, null...); // so I have to write all those nulls once } } var request = Message.minimalRequest(.....); var res = method2Test(message); // put your favorite assertion here// With optional fields in records there could be changed for something like this. record Message (String id, String document, String name?, String lastname?, String email? .... (another 20 nullable fields)){} Message request with {id: "XXXXXXXX"; document: "NNN-NNNNNN"} var res = method2Test(message); // put your favorite assertion here// I hope this presented use-case it's useful Best regards! -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.1993grajales at gmail.com Tue Mar 11 15:53:46 2025 From: david.1993grajales at gmail.com (david Grajales) Date: Tue, 11 Mar 2025 10:53:46 -0500 Subject: About the possibility of using JEP468 to inspire optional fields in records for domain contracts modeling. In-Reply-To: References: Message-ID: Indeed that might solve the problem (as it would also solve the issues JEP 468 tries to address btw) but it's not the actual matter i wanted to point out. This matter is more about data modeling and the use-case is just a personal example for explanation. The real issue is currently records are the java construct to model data but they lack the ergonomics and semantics to tell which fields are strictly mandatory and necessary other than creating static methods that acts like custom constructors, they assume all fields are mandatory and must be set manually (even to null). Maybe they should have those ergonomics and semantics or maybe they shouldn't and are much less important than I assume. I am not a language designer so I am not going to discuss further since I am very confident the amber team members know best. Best regards and always yours. El mar, 11 mar 2025 a la(s) 10:29?a.m., Anatoly Kupriyanov ( kan.izh at gmail.com) escribi?: > Does the stuff like https://github.com/Randgalt/record-builder solve the > problem? It doesn't sound as it needs changes in the language. > > On Tue, 11 Mar 2025, 14:48 david Grajales, > wrote: > >> Hi Amber team. I would like to share some thoughts based on real use >> cases I am dealing with at work. >> >> >> I know is very likely you have already thought about something like this and I don't know if this would be the best solution for the use case presented. >> >> My intention is not to propose this as "the solution" but instead just present a personal use-case based on my actual job and a naive solution that crossed my mind in the first 15 minutes. >> >> So please pay more attention to the use case and "the problem" rather than the proposed "solution" which is actually just a mean to explain the problem >> >> >> Nowadays to create a new record object we must set the value to all it >> fields, even the ones that might be null. >> >> record User (String name, String email){} >> var userWithoutEmail = new User ("name", null) >> >> This is good since it forces us to set all fields to a valid state and >> null can be a valid state. This is useful for things like JSON >> serialization; null fields in JSON are usually not serialized, which saves >> some bandwidth, in very large JSON structures that only have an small set >> of mandatory fields, this is very common in banks that happens to be >> international, since they usually use the same Core for all countries but >> each country may have different requirements (for example in some countries >> it's mandatory for people to provide 2 lastnames but in other countries >> usually you only have one lastname). >> >> To achieve this I usually do the opposite of withers, let me introduce >> you to the "withouts" >> >> record User (String name, String email){ >> >> public static withoutEmail(String name){ >> >> return new User(name, null); >> } >> } >> var userWithoutEmail = User.withoutEmail(name); >> >> The example is very basic for explanatory purposes and for a record with >> only 2 fields this can be an overkill, but for bigger records it makes a >> lot of sense, specially if only few fields between dozens are actually >> mandatory. >> >> Why not use a class instead? Serialization. records' serialization uses >> the record constructor, which means it's safer since you can make format >> and safety validations in the data before the record is built. >> >> nowadays to make sure all the mandatory fields are set, I do something >> like this. >> >> record User (String name, String email){ >> User{ >> if(name == null) >> throw new IllegalArgumentException("name field it's mandatory"); >> } >> } >> >> >> With derived record creation (or something equivalent but for direct >> creation) and nullability it would be possible and very handy to be able to >> declare optional fields that would compile to null (or zero in case of >> primitives) >> >> >> *Please ignore the straw man syntax from here.* >> >> record User (String name!, String email? ){} >> User userWithoutEmail with { name : "name"} >> >> This would make this feature in java to behave similar to TypeScript's >> interfaces, which are used to model data >> >> export interface User { >> name: String! >> email: String? >> } >> >> >> To me one of the most useful use cases of this would be for writing >> unitary tests and mocks. >> >> when writing tests sometimes you want to test the behaviour of your >> contracts (the domain objects) when they carry only the bare required >> fields, if one has very large json objects to try out but only a small set >> of mandatory fields usually it's easier to write down the json string and >> pass it to jackson or gson, with this we could use the domain object >> directly. >> >> >> Regular test if the domain object has many optional fields >> >> >> record Message (String id, String document, String name, String lastname, String email.... (another 20 fields)){} >> >> >> var request = >> """{ >> id: "XXXXXXX", >> document: "NNN-NNNNN" >> }""" >> >> >> var message = gson.fromJson(request, Message.class); >> var res = method2Test(message); >> // put your favorite assertion here// >> >> >> this has the issue you don't have help from the compiler in case you want to represent different scenarios (formatting data, invalid fields, etc) >> >> this is why I usually do "whitouts" for this kind of records. >> >> >> record Message (String id, String document, String name, String lastname, String email.... (another 20 fields)){ >> >> public Static Message minimalRequest(String id, String document){ >> >> return new Message (id, document, lastname, email, null, null...); >> >> // so I have to write all those nulls once >> >> } >> >> } >> >> var request = Message.minimalRequest(.....); >> >> var res = method2Test(message); >> >> // put your favorite assertion here// >> >> >> With optional fields in records there could be changed for something like >> this. >> >> record Message (String id, String document, String name?, String lastname?, String email? .... (another 20 nullable fields)){} >> >> Message request with {id: "XXXXXXXX"; document: "NNN-NNNNNN"} >> var res = method2Test(message); >> // put your favorite assertion here// >> >> I hope this presented use-case it's useful >> >> Best regards! >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Tue Mar 11 17:22:58 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 11 Mar 2025 13:22:58 -0400 Subject: About the possibility of using JEP468 to inspire optional fields in records for domain contracts modeling. In-Reply-To: References: Message-ID: <2d894fd4-c37c-4051-b4f6-632f12b08147@oracle.com> The problem you are grappling with here is an important one -- optionality.? What you really want to say is that some of the components of your record are required (like name), and others are optional, and you are using the convention of null to mark which components are not present.? And you would like for the notion of which components are optional to be part of the programming model, so users and compilers alike can ensure correct use.? And, you observe that Java is getting nullity control, perhaps those can be used to capture optionality in the type system as well. This is all reasonable, and similar ideas have been discussed.? I think it is safe to say there are two camps here: one that finds the use of nullity control to capture optionality to be a pragmatic approach, and another that views it as mixing concerns. There are arguments on both sides of this debate (we don't have to have it again here), but I think it's fair to say that this is one of the ideas that is on the table.? (This gets especially interesting if we are ever able to instantiate objects nominally, because then you could say `new Foo(a:1, z: 26)`, and omit b-y if they are optional.? (And we're not going to discuss this possibility again for quite some time; there are a lot of higher-priority things between here and the possibility of there.)) The topic of using (abusing? distorting?) `with` as a way to backdoor optional parameters into the language has come up a number of times, and we've consistently said "these are not the droids you are looking for."? So while we understand the goal (instantiating objects without having to specify all non-required parameters), and we agree that the goal is valuable, it is pretty clear that this is the wrong way to get there, and that the many suggestions to use `with` in this manner are an attempt at shortcutting the language-design process to get it sooner by piggybacking it on something else.? But we don't work this way. If this is a feature worth having, it is feature worth properly designing. Cheers, -Brian On 3/11/2025 10:48 AM, david Grajales wrote: > > Hi Amber team. I would like to share some thoughts based on real use > cases I am dealing with at work. > > > I know is verylikely you have already thought about something like this and I don't > know if this would be the best solution for the use case presented. > My intention is not to propose this as "the solution" but instead just > present a personal use-case based on my actual job and a naive > solution that crossed my mind in the first 15 minutes. > So please pay more attention to the use case and "the problem" rather > than the proposed "solution" which is actually just a mean to explain > the problem > > > Nowadays to create a new record object we must set the value to all it > fields, even the ones that might be null. > > record User (String name, String email){} > var userWithoutEmail = new User ("name", null) > > This is good since it forces us to set all fields to a valid state and > null can be a valid state. This is useful for things like JSON > serialization; null fields in JSON are usually not serialized, which > saves some bandwidth, in very large JSON structures that only have an > small set of mandatory fields, this is very common in banks that > happens to be international, since they usually use the same Core for > all countries but each country may have different requirements (for > example in some countries it's mandatory for people to provide 2 > lastnames but in other countries usually you only have one lastname). > > To achieve this I usually do the opposite of withers, let me introduce > you to the "withouts" > > record User (String name, String email){ > > public static withoutEmail(String name){ > > return new User(name, null); > } > } > var userWithoutEmail = User.withoutEmail(name); > > The example is very basic for explanatory purposes and for a record > with only 2 fields this can be an overkill, but for bigger records it > makes a lot of sense, specially if only few fields between dozens are > actually mandatory. > > Why not use a class instead? Serialization. records' serialization > uses the record constructor, which means it's safer since you can make > format and safety validations in the data before the record is built. > > nowadays to make sure all the mandatory fields are set, I do something > like this. > > record User (String name, String email){ > User{ > if(name == null) > throw new IllegalArgumentException("name field it's mandatory"); > } > } > > > With derived record creation (or something equivalent but for direct > creation) and nullability it would be possible and very handy to be > able to declare optional fields that would compile to null (or zero in > case of primitives) > > > **Please ignore the straw man syntax from here.** > > record User (String name!, String email? ){} > User userWithoutEmail with { name : "name"} > > This would make this feature in java to behave similar to TypeScript's > interfaces, which are used to model data > > export interface User { > name: String! > email: String? > } > > > To me one of the most useful use cases of this would be for writing > unitary tests and mocks. > > when writing tests sometimes you want to test the behaviour of your > contracts (the domain objects) when they carry only the bare required > fields, if one has very large json objects to try out but only a small > set of mandatory fields usually it's easier to write down the json > string and pass it to jackson or gson, with this we could use the > domain object directly. > > > Regular test if the domain object has many optional fields > > record Message (String id, String document, String name, String > lastname, String email.... (another 20 fields)){} > > > var request = > """{ > id: "XXXXXXX", > document: "NNN-NNNNN" > }""" > var message = gson.fromJson(request, Message.class); > var res = method2Test(message); > // put your favorite assertion here// > this has the issue you don't have help from the compiler in case you want to represent different scenarios (formatting data, invalid fields, etc) > this is why I usually do "whitouts" for this kind of records. > record Message (String id, String document, String name, String lastname, String email.... (another 20 fields)){ > public Static Message minimalRequest(String id, String document){ > return new Message (id, document, lastname, email, null, null...); > // so I have to write all those nulls once > } > } > var request = Message.minimalRequest(.....); > var res = method2Test(message); > // put your favorite assertion here// > > > With optional fields in records there could be changed for something > like this. > > record Message (String id, String document, String name?, String > lastname?, String email? .... (another 20 nullable fields)){} > > Message request with {id: "XXXXXXXX"; document: "NNN-NNNNNN"} > var res = method2Test(message); > // put your favorite assertion here// > I hope this presented use-case it's useful > Best regards! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at mccue.dev Tue Mar 11 17:40:59 2025 From: ethan at mccue.dev (Ethan McCue) Date: Tue, 11 Mar 2025 13:40:59 -0400 Subject: About the possibility of using JEP468 to inspire optional fields in records for domain contracts modeling. In-Reply-To: References: Message-ID: Unfortunately there is nothing which will auto-derive a User(String name) { this(name, null, ... more nulls ...); } constructor for you. Part of the problem is that "optional to specify" doesn't always mean "has a default of null." Example: record User(String name, String email, List pets) { User { Objects.requireNonNull(pets); } User(String name) { this(name, null, List.of()) } } In this case both email and pets are optional to specify, but null isn't actually the value you want for an unspecified list of pets. The proposal for nullable and null-restricted types might be of interest to you (https://openjdk.org/jeps/8303099), but absent user-land code generation (with a heuristic like nullable == optional to specify) I don't imagine there could be a mechanism for "optional record components" that wouldn't also encroach upon the more general problem of "named method invocation with default values." And that is a tough problem. On Tue, Mar 11, 2025 at 12:29?PM david Grajales < david.1993grajales at gmail.com> wrote: > Indeed that might solve the problem (as it would also solve the issues JEP > 468 tries to address btw) but it's not the actual matter i wanted to point > out. This matter is more about data modeling and the use-case is just a > personal example for explanation. The real issue is currently records are > the java construct to model data but they lack the ergonomics and > semantics to tell which fields are strictly mandatory and necessary other > than creating static methods that acts like custom constructors, they > assume all fields are mandatory and must be set manually (even to null). > Maybe they should have those ergonomics and semantics or maybe they > shouldn't and are much less important than I assume. > > I am not a language designer so I am not going to discuss further since I > am very confident the amber team members know best. > > Best regards and always yours. > > > > El mar, 11 mar 2025 a la(s) 10:29?a.m., Anatoly Kupriyanov ( > kan.izh at gmail.com) escribi?: > >> Does the stuff like https://github.com/Randgalt/record-builder solve the >> problem? It doesn't sound as it needs changes in the language. >> >> On Tue, 11 Mar 2025, 14:48 david Grajales, >> wrote: >> >>> Hi Amber team. I would like to share some thoughts based on real use >>> cases I am dealing with at work. >>> >>> >>> I know is very likely you have already thought about something like this and I don't know if this would be the best solution for the use case presented. >>> >>> My intention is not to propose this as "the solution" but instead just present a personal use-case based on my actual job and a naive solution that crossed my mind in the first 15 minutes. >>> >>> So please pay more attention to the use case and "the problem" rather than the proposed "solution" which is actually just a mean to explain the problem >>> >>> >>> Nowadays to create a new record object we must set the value to all it >>> fields, even the ones that might be null. >>> >>> record User (String name, String email){} >>> var userWithoutEmail = new User ("name", null) >>> >>> This is good since it forces us to set all fields to a valid state and >>> null can be a valid state. This is useful for things like JSON >>> serialization; null fields in JSON are usually not serialized, which saves >>> some bandwidth, in very large JSON structures that only have an small set >>> of mandatory fields, this is very common in banks that happens to be >>> international, since they usually use the same Core for all countries but >>> each country may have different requirements (for example in some countries >>> it's mandatory for people to provide 2 lastnames but in other countries >>> usually you only have one lastname). >>> >>> To achieve this I usually do the opposite of withers, let me introduce >>> you to the "withouts" >>> >>> record User (String name, String email){ >>> >>> public static withoutEmail(String name){ >>> >>> return new User(name, null); >>> } >>> } >>> var userWithoutEmail = User.withoutEmail(name); >>> >>> The example is very basic for explanatory purposes and for a record with >>> only 2 fields this can be an overkill, but for bigger records it makes a >>> lot of sense, specially if only few fields between dozens are actually >>> mandatory. >>> >>> Why not use a class instead? Serialization. records' serialization uses >>> the record constructor, which means it's safer since you can make format >>> and safety validations in the data before the record is built. >>> >>> nowadays to make sure all the mandatory fields are set, I do something >>> like this. >>> >>> record User (String name, String email){ >>> User{ >>> if(name == null) >>> throw new IllegalArgumentException("name field it's mandatory"); >>> } >>> } >>> >>> >>> With derived record creation (or something equivalent but for direct >>> creation) and nullability it would be possible and very handy to be able to >>> declare optional fields that would compile to null (or zero in case of >>> primitives) >>> >>> >>> *Please ignore the straw man syntax from here.* >>> >>> record User (String name!, String email? ){} >>> User userWithoutEmail with { name : "name"} >>> >>> This would make this feature in java to behave similar to TypeScript's >>> interfaces, which are used to model data >>> >>> export interface User { >>> name: String! >>> email: String? >>> } >>> >>> >>> To me one of the most useful use cases of this would be for writing >>> unitary tests and mocks. >>> >>> when writing tests sometimes you want to test the behaviour of your >>> contracts (the domain objects) when they carry only the bare required >>> fields, if one has very large json objects to try out but only a small set >>> of mandatory fields usually it's easier to write down the json string and >>> pass it to jackson or gson, with this we could use the domain object >>> directly. >>> >>> >>> Regular test if the domain object has many optional fields >>> >>> >>> record Message (String id, String document, String name, String lastname, String email.... (another 20 fields)){} >>> >>> >>> var request = >>> """{ >>> id: "XXXXXXX", >>> document: "NNN-NNNNN" >>> }""" >>> >>> >>> var message = gson.fromJson(request, Message.class); >>> var res = method2Test(message); >>> // put your favorite assertion here// >>> >>> >>> this has the issue you don't have help from the compiler in case you want to represent different scenarios (formatting data, invalid fields, etc) >>> >>> this is why I usually do "whitouts" for this kind of records. >>> >>> >>> record Message (String id, String document, String name, String lastname, String email.... (another 20 fields)){ >>> >>> public Static Message minimalRequest(String id, String document){ >>> >>> return new Message (id, document, lastname, email, null, null...); >>> >>> // so I have to write all those nulls once >>> >>> } >>> >>> } >>> >>> var request = Message.minimalRequest(.....); >>> >>> var res = method2Test(message); >>> >>> // put your favorite assertion here// >>> >>> >>> With optional fields in records there could be changed for something >>> like this. >>> >>> record Message (String id, String document, String name?, String lastname?, String email? .... (another 20 nullable fields)){} >>> >>> Message request with {id: "XXXXXXXX"; document: "NNN-NNNNNN"} >>> var res = method2Test(message); >>> // put your favorite assertion here// >>> >>> I hope this presented use-case it's useful >>> >>> Best regards! >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.1993grajales at gmail.com Tue Mar 11 18:28:24 2025 From: david.1993grajales at gmail.com (david Grajales) Date: Tue, 11 Mar 2025 13:28:24 -0500 Subject: About the possibility of using JEP468 to inspire optional fields in records for domain contracts modeling. In-Reply-To: <2d894fd4-c37c-4051-b4f6-632f12b08147@oracle.com> References: <2d894fd4-c37c-4051-b4f6-632f12b08147@oracle.com> Message-ID: Hi Brian. Thanks for the answer. I totally agree about using with with expressions for this is a bad idea, I just made use of it for explanation purposes and agree this should be properly designed. I am happy to know this matter is on the table, even if it takes quite some time to get there. best regards and wishes to all people involved in the evolution of the java platform. El mar, 11 mar 2025 a la(s) 12:23?p.m., Brian Goetz (brian.goetz at oracle.com) escribi?: > The problem you are grappling with here is an important one -- > optionality. What you really want to say is that some of the components of > your record are required (like name), and others are optional, and you are > using the convention of null to mark which components are not present. And > you would like for the notion of which components are optional to be part > of the programming model, so users and compilers alike can ensure correct > use. And, you observe that Java is getting nullity control, perhaps those > can be used to capture optionality in the type system as well. > > This is all reasonable, and similar ideas have been discussed. I think it > is safe to say there are two camps here: one that finds the use of nullity > control to capture optionality to be a pragmatic approach, and another that > views it as mixing concerns. There are arguments on both sides of this > debate (we don't have to have it again here), but I think it's fair to say > that this is one of the ideas that is on the table. (This gets especially > interesting if we are ever able to instantiate objects nominally, because > then you could say `new Foo(a:1, z: 26)`, and omit b-y if they are > optional. (And we're not going to discuss this possibility again for quite > some time; there are a lot of higher-priority things between here and the > possibility of there.)) > > The topic of using (abusing? distorting?) `with` as a way to backdoor > optional parameters into the language has come up a number of times, and > we've consistently said "these are not the droids you are looking for." So > while we understand the goal (instantiating objects without having to > specify all non-required parameters), and we agree that the goal is > valuable, it is pretty clear that this is the wrong way to get there, and > that the many suggestions to use `with` in this manner are an attempt at > shortcutting the language-design process to get it sooner by piggybacking > it on something else. But we don't work this way. If this is a feature > worth having, it is feature worth properly designing. > > Cheers, > -Brian > > > > On 3/11/2025 10:48 AM, david Grajales wrote: > > Hi Amber team. I would like to share some thoughts based on real use cases > I am dealing with at work. > > > I know is very likely you have already thought about something like this and I don't know if this would be the best solution for the use case presented. > > My intention is not to propose this as "the solution" but instead just present a personal use-case based on my actual job and a naive solution that crossed my mind in the first 15 minutes. > > So please pay more attention to the use case and "the problem" rather than the proposed "solution" which is actually just a mean to explain the problem > > > Nowadays to create a new record object we must set the value to all it > fields, even the ones that might be null. > > record User (String name, String email){}var userWithoutEmail = new User ("name", null) > > This is good since it forces us to set all fields to a valid state and > null can be a valid state. This is useful for things like JSON > serialization; null fields in JSON are usually not serialized, which saves > some bandwidth, in very large JSON structures that only have an small set > of mandatory fields, this is very common in banks that happens to be > international, since they usually use the same Core for all countries but > each country may have different requirements (for example in some countries > it's mandatory for people to provide 2 lastnames but in other countries > usually you only have one lastname). > > To achieve this I usually do the opposite of withers, let me introduce you > to the "withouts" > > record User (String name, String email){ public static withoutEmail(String name){ return new User(name, null); }}var userWithoutEmail = User.withoutEmail(name); > > The example is very basic for explanatory purposes and for a record with > only 2 fields this can be an overkill, but for bigger records it makes a > lot of sense, specially if only few fields between dozens are actually > mandatory. > > Why not use a class instead? Serialization. records' serialization uses > the record constructor, which means it's safer since you can make format > and safety validations in the data before the record is built. > > nowadays to make sure all the mandatory fields are set, I do something > like this. > > record User (String name, String email){ > User{ > if(name == null) > throw new IllegalArgumentException("name field it's mandatory"); > } > } > > > With derived record creation (or something equivalent but for direct > creation) and nullability it would be possible and very handy to be able to > declare optional fields that would compile to null (or zero in case of > primitives) > > > *Please ignore the straw man syntax from here.* > > record User (String name!, String email? ){}User userWithoutEmail with { name : "name"} > > This would make this feature in java to behave similar to TypeScript's > interfaces, which are used to model data > > export interface User { name: String! email: String?} > > > To me one of the most useful use cases of this would be for writing > unitary tests and mocks. > > when writing tests sometimes you want to test the behaviour of your > contracts (the domain objects) when they carry only the bare required > fields, if one has very large json objects to try out but only a small set > of mandatory fields usually it's easier to write down the json string and > pass it to jackson or gson, with this we could use the domain object > directly. > > > Regular test if the domain object has many optional fields > > record Message (String id, String document, String name, String lastname, String email.... (another 20 fields)){} > > var request = """{ id: "XXXXXXX", document: "NNN-NNNNN"}""" > > var message = gson.fromJson(request, Message.class);var res = method2Test(message);// put your favorite assertion here// > > this has the issue you don't have help from the compiler in case you want to represent different scenarios (formatting data, invalid fields, etc) > > this is why I usually do "whitouts" for this kind of records. > > record Message (String id, String document, String name, String lastname, String email.... (another 20 fields)){ > > public Static Message minimalRequest(String id, String document){ > > return new Message (id, document, lastname, email, null, null...); > > // so I have to write all those nulls once > > } > > } > > var request = Message.minimalRequest(.....); > > var res = method2Test(message); > > // put your favorite assertion here// > > > With optional fields in records there could be changed for something like > this. > > record Message (String id, String document, String name?, String lastname?, String email? .... (another 20 nullable fields)){} > Message request with {id: "XXXXXXXX"; document: "NNN-NNNNNN"}var res = method2Test(message);// put your favorite assertion here// > > I hope this presented use-case it's useful > > Best regards! > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at int4.org Tue Mar 11 20:37:24 2025 From: john at int4.org (John Hendrikx) Date: Tue, 11 Mar 2025 21:37:24 +0100 Subject: About the possibility of using JEP468 to inspire optional fields in records for domain contracts modeling. In-Reply-To: References: Message-ID: <10a87f18-eafc-4cbe-b541-0413fc788eee@int4.org> On 11/03/2025 15:48, david Grajales wrote: > Why not use a class instead? Serialization. records' serialization > uses the record constructor, which means it's safer since you can make > format and safety validations in the data before the record is built. While to deserialize a record, you are indeed forced to use the constructor, nothing is stopping you from doing the exact same thing with a class.? Serialization frameworks do not need access to setters or fields.? A framework like Jackson can use the constructor perfectly fine, and you can declare all fields private and final.? It is just a matter of configuring it as such. Such a constructor can then be outfitted with validations just like a record constructor, and it will be enforced upon deserialization. --John From davidalayachew at gmail.com Fri Mar 14 23:13:58 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Fri, 14 Mar 2025 19:13:58 -0400 Subject: Question about IO.println In-Reply-To: References: Message-ID: Hey Stuart, Thanks for the response. Just to confirm, you are saying that IO.println would have a method that takes in StringTemplates? Or is it a case of calling join on our tenplates, and the IO API remains unchanged? Either way, StringTemplates are going to have a rippling effect on the Java ecosystem. I'm excited for it. On Fri, Mar 7, 2025, 4:14?PM Stuart Marks wrote: > Hi, > > Our goal with the IO class is to have it add as few mechanisms as > possible. Anything > it can do, one should easily be able to do with existing classes like > PrintStream or > BufferedReader. So, we wouldn't add a varargs method to IO itself without > having one > in PrintStream or something. > > Now, should PrintStream have a varargs overload of println? Well, println > first > appeared in JDK 1.0 well before varargs existed and the answer then was to > use the + > string concatenation operator for multiple values. This still works, > though there > are cases where it doesn't work very well. > > When varargs was added (5.0) PrintStream got printf with varargs, but > println wasn't > retrofitted with varargs. > > And there will be string templates, which will allow one to embed multiple > values > unobtrusively, so there's no need for varargs here. And a string templates > should be > directly usable from IO.println, so it'll come for "free". > > Thus I don't see a need to add varargs overloads here. > > s'marks > > > > On 3/4/25 5:03 AM, David Alayachew wrote: > > Hello Amber Dev Team and Core Libs Dev Team, > > > > Another reddit discussion popped up today about IO.println(), and one of > the > > comments mentioned that they wanted something along the lines of this. > > > > IO.println(num1, num2, num3); //prints out "1 2 3" > > > > I proposed that maybe a better option would be a String.join overload. > So, instead > > of String.join(String delim, String... elements), there would be > String.join(String > > delim, Object... elements), with each object getting toString() called > on it. > > > > What are your thoughts on either of these ideas? I actually think the > IO.println() > > version is nice, but I felt like String.join made a slightly better > compromise. > > > > Another commentor mentioned that this will be easier with String > Templates too, so > > maybe it is better to wait for that. I don't think String templates are > a bad idea > > here, but it also felt like overkill imo. A library function seems like > a better fit. > > > > Thank you for your time and thoughts. > > David Alayachew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Sun Mar 16 23:56:28 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Sun, 16 Mar 2025 19:56:28 -0400 Subject: I'm finally getting around to making that FAQ Message-ID: Hello Amber Dev Team, I am finally getting around to making that FAQ that we have all been talking about but not doing anything about for a few years. Just wanted to go over structure. (Of course, in the name of actually getting a pull request through so that we can get something DONE, I won't wait for responses before committing.) 1. I'm going to post the FAQ on the amber-docs github -- https://github.com/openjdk/amber-docs. 1. This just makes sense -- want to learn about Amber? Go to the amber docs. FAQ is a very reasonable thing to have on there imo. 2. I am going to have an *INDIVIDUAL FAQ* for each JEP. 1. Obviously, only the "final" JEP's. None of the preview ones. The amber-docs already organized this way, so it will be easy to just add onto it. 2. I expect push back on the "FAQ for each feature" idea, and I can be convinced otherwise. Shuffling around answers back and forth is low effort too, so this won't be an issue if I need to undo my work. But, this just makes things easier, IMO. 3. Plus, precedent was set with Local Variable Type Inference. It has its own FAQ, so might be wise to emulate IMO. 3. I will only post summarized questions and summarized answers, with links to the original answers. 1. For summarized questions, I don't have a super strict definition for this. I am basically going to try and group together questions into meaningfully distinct groups, then summarize for each group. 2. The answers, however, will be *nothing but pure quotes* of the original answer. I might "String [...] parts of [...] the same quote [...] together", but I'll act in good faith to try and retain the intent. And either way, the link is right there, and this is an open source repo. Make a PR if you all think I get it wrong. 4. I will limit answers to only those given by direct members of the Amber Dev Team, and only for answers given on this mailing list or StackOverflow. 1. The list of members can be found here -- https://openjdk.org/census#amber 2. The reason for limiting to only those 2 sites is to avoid link-rot, where a post is deleted, thus, removing the question that one of these answers is for. It's important to be able to see the original question that the answer is responding too. No question summary that I make will be able to fully capture the nuance of each question. I will be focusing on doing this nice and sweet and slow. I'll make it a goal to add 1 or 2 entries every week at a minimum. Consistency is key here. No duds or half-finished work. And finally, once the general structure is in place and people have more or less settled on a design, please feel free to jump in. As answers get given to common questions, make a PR to index them here. it's a hell of a lot easier to index an answer given days ago as opposed to trying to dig through the mailing list archives from years ago lol. Thank you for your time and consideration. David Alayachew -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Mon Mar 17 00:04:44 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Sun, 16 Mar 2025 20:04:44 -0400 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: Also, minor preference for organizing answers in reverse-chronological order. I'll probably list the source and the timestamp next to each answer. Again, details can be hashed out here, but I'll make something, just so we can get some movement on this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Mon Mar 17 00:48:17 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Sun, 16 Mar 2025 20:48:17 -0400 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: Also, I think it would be super important to be able to link to the specific question on the FAQ. As these things grow, we want to be able to just link directly to the relevant question, as opposed to telling people to just Ctrl+F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Mon Mar 17 02:42:33 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Sun, 16 Mar 2025 22:42:33 -0400 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: First Pull Request has been made. It has 4 entries in it. I will probably make it my weekly weekend activity to add at least 1 or 2. -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Mar 17 02:48:32 2025 From: duke at openjdk.org (duke) Date: Mon, 17 Mar 2025 02:48:32 GMT Subject: [amber-docs] RFR: Adding first FAQ, per discussion in various locations lol In-Reply-To: References: Message-ID: <2rcRjPvqgjWTL063qW-WufHQBO0pmL2zjgXLetaPGSc=.1a8e5af6-20f2-4501-8d01-19f9c08eedc1@github.com> On Mon, 17 Mar 2025 02:41:40 GMT, David Alayachew wrote: > I'm not married to the format. The hard work, of finding the discussions and linking them inline, has been done. Just want to make sure that we get SOMETHING out there, so that we can have a definitive place to link new folks too when they have questions, for further reading. @davidalayachew Your change (at version d8590593d18d17e662e8fbd68a4de89256a66960) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/amber-docs/pull/27#issuecomment-2727895962 From duke at openjdk.org Mon Mar 17 02:48:32 2025 From: duke at openjdk.org (David Alayachew) Date: Mon, 17 Mar 2025 02:48:32 GMT Subject: [amber-docs] RFR: Adding first FAQ, per discussion in various locations lol Message-ID: I'm not married to the format. The hard work, of finding the discussions and linking them inline, has been done. Just want to make sure that we get SOMETHING out there, so that we can have a definitive place to link new folks too when they have questions, for further reading. ------------- Commit messages: - Update _index.md - Create simple_source_files_and_instance_main_methods.md Changes: https://git.openjdk.org/amber-docs/pull/27/files Webrev: https://webrevs.openjdk.org/?repo=amber-docs&pr=27&range=00 Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.org/amber-docs/pull/27.diff Fetch: git fetch https://git.openjdk.org/amber-docs.git pull/27/head:pull/27 PR: https://git.openjdk.org/amber-docs/pull/27 From magnus.ihse.bursie at oracle.com Tue Mar 18 11:15:47 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Mar 2025 12:15:47 +0100 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: On 2025-03-17 03:42, David Alayachew wrote: > First Pull Request has been made. It has 4 entries in it. I will > probably make it my weekly weekend activity to add at least 1 or 2. Hooray! Thank you for your efforts. As an amber lurker, I think this is just about what I wanted to see. Or, to put it differently, I think this passes the "good enough" bar with flying marks, and that given that the alternative is "nothing at all", then "good enough" is all that was required. As you say, additional tweaking can always be done as we go along. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Tue Mar 18 11:36:09 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 18 Mar 2025 07:36:09 -0400 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: Agreed. I find that "ugly, but functional" tends to motivate people. At least this way, the folks who care about formatting only have to fix formatting. They don't have to do all of the digging. And for those reading along, let me assert -- feel free to rework my design however you like. I'm just giving SOME design, so that it's up and usable as is. On Tue, Mar 18, 2025 at 7:15?AM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2025-03-17 03:42, David Alayachew wrote: > > First Pull Request has been made. It has 4 entries in it. I will probably > make it my weekly weekend activity to add at least 1 or 2. > > Hooray! Thank you for your efforts. > > As an amber lurker, I think this is just about what I wanted to see. Or, > to put it differently, I think this passes the "good enough" bar with > flying marks, and that given that the alternative is "nothing at all", then > "good enough" is all that was required. As you say, additional tweaking can > always be done as we go along. > > /Magnus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Tue Mar 18 11:39:30 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 18 Mar 2025 07:39:30 -0400 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: Also, surprisingly enough, a lot of the newer feature explanations have occurred over Reddit, as opposed to the mailing lists, and even less so for StackOverflow. Are we good with me including Reddit responses from official Amber Dev Team Members? I don't like doing this, since reddit posts tend to get deleted often, thus, losing us the question text that was being answered. But we would be leaving a lot of good explanations on the table by leaving out reddit. Especially for new features. I'll start including them for now, but again, feel free to delete it in the pull request if you all disagree. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Tue Mar 18 11:44:09 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 18 Mar 2025 07:44:09 -0400 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: > Are we good with me including Reddit responses > from official Amber Dev Team Members? *Amber Dev Team + Ron. Apparently, he's not on Amber, according to the census. Plus, he's pretty chatty about Amber on Reddit. Frankly, he was the one I was thinking of when I sent that email. https://openjdk.org/census#amber -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at mccue.dev Tue Mar 18 14:26:25 2025 From: ethan at mccue.dev (Ethan McCue) Date: Tue, 18 Mar 2025 10:26:25 -0400 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: Forgot to reply-all: If reddit stuff is included, the referenced conversations should probably be backed up + those back ups included in some way. There is reason to doubt the longevity of free access to that as a forum. On Tue, Mar 18, 2025, 9:44?AM David Alayachew wrote: > Also, surprisingly enough, a lot of the newer feature explanations have > occurred over Reddit, as opposed to the mailing lists, and even less so for > StackOverflow. > > Are we good with me including Reddit responses from official Amber Dev > Team Members? I don't like doing this, since reddit posts tend to get > deleted often, thus, losing us the question text that was being answered. > > But we would be leaving a lot of good explanations on the table by leaving > out reddit. Especially for new features. > > I'll start including them for now, but again, feel free to delete it in > the pull request if you all disagree. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Tue Mar 18 22:29:02 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 18 Mar 2025 18:29:02 -0400 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: Thanks Ethan. Will do, I'll have both the link and backups for all reddit links. I'm going to add 1 or 2 more today. On Tue, Mar 18, 2025, 10:26?AM Ethan McCue wrote: > Forgot to reply-all: > > If reddit stuff is included, the referenced conversations should probably > be backed up + those back ups included in some way. > > There is reason to doubt the longevity of free access to that as a forum. > > On Tue, Mar 18, 2025, 9:44?AM David Alayachew > wrote: > >> Also, surprisingly enough, a lot of the newer feature explanations have >> occurred over Reddit, as opposed to the mailing lists, and even less so for >> StackOverflow. >> >> Are we good with me including Reddit responses from official Amber Dev >> Team Members? I don't like doing this, since reddit posts tend to get >> deleted often, thus, losing us the question text that was being answered. >> >> But we would be leaving a lot of good explanations on the table by >> leaving out reddit. Especially for new features. >> >> I'll start including them for now, but again, feel free to delete it in >> the pull request if you all disagree. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Mar 19 01:45:40 2025 From: duke at openjdk.org (David Alayachew) Date: Wed, 19 Mar 2025 01:45:40 GMT Subject: [amber-docs] RFR: FAQ [v2] In-Reply-To: References: Message-ID: <-yYSwRltqjx1I5h9UGI86Nf90MRcgD9_qkL1FNyj320=.47cb5247-10a5-4a4b-8e22-572ad385de84@github.com> > I'm not married to the format. The hard work, of finding the discussions and linking them inline, has been done. Just want to make sure that we get SOMETHING out there, so that we can have a definitive place to link new folks too when they have questions, for further reading. David Alayachew has updated the pull request incrementally with two additional commits since the last revision: - Update _index.md Need to update it here too. - Update and rename simple_source_files_and_instance_main_methods.md to jep_495_simple_source_files_and_instance_main_methods.md Names change, and people seem to know this more by the JEP #, as opposed to the name. ------------- Changes: - all: https://git.openjdk.org/amber-docs/pull/27/files - new: https://git.openjdk.org/amber-docs/pull/27/files/d8590593..fff7c75c Webrevs: - full: https://webrevs.openjdk.org/?repo=amber-docs&pr=27&range=01 - incr: https://webrevs.openjdk.org/?repo=amber-docs&pr=27&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/amber-docs/pull/27.diff Fetch: git fetch https://git.openjdk.org/amber-docs.git pull/27/head:pull/27 PR: https://git.openjdk.org/amber-docs/pull/27 From duke at openjdk.org Wed Mar 19 01:50:54 2025 From: duke at openjdk.org (David Alayachew) Date: Wed, 19 Mar 2025 01:50:54 GMT Subject: [amber-docs] RFR: FAQ [v3] In-Reply-To: References: Message-ID: > I'm not married to the format. The hard work, of finding the discussions and linking them inline, has been done. Just want to make sure that we get SOMETHING out there, so that we can have a definitive place to link new folks too when they have questions, for further reading. David Alayachew has updated the pull request incrementally with one additional commit since the last revision: Update _index.md Time to add the next FAQ ------------- Changes: - all: https://git.openjdk.org/amber-docs/pull/27/files - new: https://git.openjdk.org/amber-docs/pull/27/files/fff7c75c..aeb42b72 Webrevs: - full: https://webrevs.openjdk.org/?repo=amber-docs&pr=27&range=02 - incr: https://webrevs.openjdk.org/?repo=amber-docs&pr=27&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/amber-docs/pull/27.diff Fetch: git fetch https://git.openjdk.org/amber-docs.git pull/27/head:pull/27 PR: https://git.openjdk.org/amber-docs/pull/27 From duke at openjdk.org Wed Mar 19 02:13:55 2025 From: duke at openjdk.org (David Alayachew) Date: Wed, 19 Mar 2025 02:13:55 GMT Subject: [amber-docs] RFR: FAQ [v4] In-Reply-To: References: Message-ID: > I'm not married to the format. The hard work, of finding the discussions and linking them inline, has been done. Just want to make sure that we get SOMETHING out there, so that we can have a definitive place to link new folks too when they have questions, for further reading. David Alayachew has updated the pull request incrementally with one additional commit since the last revision: Create jep_494_module_imports.md ------------- Changes: - all: https://git.openjdk.org/amber-docs/pull/27/files - new: https://git.openjdk.org/amber-docs/pull/27/files/aeb42b72..abbc2dde Webrevs: - full: https://webrevs.openjdk.org/?repo=amber-docs&pr=27&range=03 - incr: https://webrevs.openjdk.org/?repo=amber-docs&pr=27&range=02-03 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/amber-docs/pull/27.diff Fetch: git fetch https://git.openjdk.org/amber-docs.git pull/27/head:pull/27 PR: https://git.openjdk.org/amber-docs/pull/27 From duke at openjdk.org Wed Mar 19 02:21:31 2025 From: duke at openjdk.org (David Alayachew) Date: Wed, 19 Mar 2025 02:21:31 GMT Subject: [amber-docs] RFR: FAQ [v5] In-Reply-To: References: Message-ID: > I'm not married to the format. The hard work, of finding the discussions and linking them inline, has been done. Just want to make sure that we get SOMETHING out there, so that we can have a definitive place to link new folks too when they have questions, for further reading. David Alayachew has updated the pull request incrementally with five additional commits since the last revision: - Update _index.md Now, we can float FAQ's between the most recent JEP Versions. Less effort for those maintaining things later. - Update and rename jep_495_simple_source_files_and_instance_main_methods.md to simple_source_files_and_instance_main_methods.md If people need to know the JEP, that's easy enough to be able to find out by just looking up the feature name. - Update and rename jep_494_module_imports.md to module_imports.md Yeah, JEP number is not wise. - Update jep_494_module_imports.md Maybe adding the JEP number is unwise. - Update jep_495_simple_source_files_and_instance_main_methods.md Little too LOUD. Of course, this will probably get ripped out, but worth doing anyways, in case the "prototype" becomes the final product lol. ------------- Changes: - all: https://git.openjdk.org/amber-docs/pull/27/files - new: https://git.openjdk.org/amber-docs/pull/27/files/abbc2dde..cfae2ead Webrevs: - full: https://webrevs.openjdk.org/?repo=amber-docs&pr=27&range=04 - incr: https://webrevs.openjdk.org/?repo=amber-docs&pr=27&range=03-04 Stats: 8 lines in 3 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/amber-docs/pull/27.diff Fetch: git fetch https://git.openjdk.org/amber-docs.git pull/27/head:pull/27 PR: https://git.openjdk.org/amber-docs/pull/27 From davidalayachew at gmail.com Wed Mar 19 02:26:45 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 18 Mar 2025 22:26:45 -0400 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: Ok, for reddit links, I went with the Wayback Machine. That's helpful too because it's widely use for immortalizing all sorts of links. I actually think we can widen our scope to pretty much any website, as long as we also include an archive link. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Wed Mar 19 02:28:00 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 18 Mar 2025 22:28:00 -0400 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: Hey, could someone make a branch for me in amber-docs? This FAQ is a new feature, so it kind of deserves its own feature branch. Plus, we can all sort of tinker around in that branch until we find a pattern we like, then merge that into main once we are happy (enough) with the solution. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Sun Mar 30 01:29:51 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Sat, 29 Mar 2025 21:29:51 -0400 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: Question for the group -- can anyone find any question about JEP 447/482/492 that might go into a FAQ? I have been going through at least one feature a week, and I am on Flexible Constructor Bodies, and I can't find any questions people seem to have with it. I have scoured (to the best of my ability) Reddit and Amber Dev. I am going to go through Amber Spec Experts next, but just wanted to see if, either I missed something in Reddit/Amber Dev, or if someone has direct/private emails that capture some questions that are "FAQ". And sorry to solo you out, but adding you directly @Archie Cobbs ! Since you gave birth to this feature lol. In the meantime, I'll add a super weak "Why do we need this feature?" to the FAQ, because that is the grand total of all that I could find for this featurefrom my search thus far. And tbf, I have good answers for it, it's just not that enticing of a question, and I feel like there are more questions I just haven't found. -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Sun Mar 30 02:38:12 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Sat, 29 Mar 2025 20:38:12 -0600 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: Hi David, There was lots of discussion on amber-dev but it may be hard to track down. I am happy to dig up some of those threads and will follow up in a few days with some links for you. Thanks a lot for putting this FAQ together! I think it will be a great resource to have. -Archie Archie L. Cobbs On Sat, Mar 29, 2025 at 7:30?PM David Alayachew wrote: > Question for the group -- can anyone find any question about JEP > 447/482/492 that might go into a FAQ? > > I have been going through at least one feature a week, and I am on > Flexible Constructor Bodies, and I can't find any questions people seem to > have with it. I have scoured (to the best of my ability) Reddit and Amber > Dev. I am going to go through Amber Spec Experts next, but just wanted to > see if, either I missed something in Reddit/Amber Dev, or if someone has > direct/private emails that capture some questions that are "FAQ". > > And sorry to solo you out, but adding you directly @Archie Cobbs > ! Since you gave birth to this feature lol. > > In the meantime, I'll add a super weak "Why do we need this feature?" to > the FAQ, because that is the grand total of all that I could find for this > featurefrom my search thus far. And tbf, I have good answers for it, it's > just not that enticing of a question, and I feel like there are more > questions I just haven't found. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Sun Mar 30 03:02:36 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Sat, 29 Mar 2025 23:02:36 -0400 Subject: I'm finally getting around to making that FAQ In-Reply-To: References: Message-ID: Thanks Archie! To help limit your search, I went through all of Amber Dev and Amber Spec Experts, from Jan 2022 up to now. I only really found a whole bunch of "Sounds great to me" and "Where should we draw the line?". It may make sense to turn some of those "Where's the line?" questions, and turn them into FAQ answers, but nothing really popped out to me. That aside, I found a lot of discussion on Amber Dev, primarily Oct/Nov 2022. That seems to be where this whole thing started. Btw, it was a very cool read to see a feature organically grow from a simple discussion to an actual JEP. It's a great guideline for how to do this right. Plus, more of it was out in the open than most JEP's, so easier to learn how to follow along. And finally, here is the work-in-progress thus far, in case you want to correct what I have done. https://github.com/openjdk/amber-docs/pull/27/files#diff-126888cfc483a0bf4a51486e84145f7b07150e75c1b28d252bf01b3f493aeba8 Thank you for your time and help! David Alayachew On Sat, Mar 29, 2025 at 10:38?PM Archie Cobbs wrote: > Hi David, > > There was lots of discussion on amber-dev but it may be hard to track > down. I am happy to dig up some of those threads and will follow up in a > few days with some links for you. > > Thanks a lot for putting this FAQ together! I think it will be a great > resource to have. > > -Archie > > Archie L. Cobbs > > > On Sat, Mar 29, 2025 at 7:30?PM David Alayachew > wrote: > >> Question for the group -- can anyone find any question about JEP >> 447/482/492 that might go into a FAQ? >> >> I have been going through at least one feature a week, and I am on >> Flexible Constructor Bodies, and I can't find any questions people seem to >> have with it. I have scoured (to the best of my ability) Reddit and Amber >> Dev. I am going to go through Amber Spec Experts next, but just wanted to >> see if, either I missed something in Reddit/Amber Dev, or if someone has >> direct/private emails that capture some questions that are "FAQ". >> >> And sorry to solo you out, but adding you directly @Archie Cobbs >> ! Since you gave birth to this feature lol. >> >> In the meantime, I'll add a super weak "Why do we need this feature?" to >> the FAQ, because that is the grand total of all that I could find for this >> featurefrom my search thus far. And tbf, I have good answers for it, it's >> just not that enticing of a question, and I feel like there are more >> questions I just haven't found. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: