From alex.buckley at oracle.com Thu Jan 2 17:57:03 2025 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 2 Jan 2025 09:57:03 -0800 Subject: Constructing records through reflection and module restrictions In-Reply-To: <87h66qjswm.fsf@mid.deneb.enyo.de> References: <87v7vv4ntl.fsf@mid.deneb.enyo.de> <6D305BE0-91A9-4261-87DB-56C7E1FCE86F@oracle.com> <87o71ngrir.fsf@mid.deneb.enyo.de> <242277097.17085797.1733610848446.JavaMail.zimbra@univ-eiffel.fr> <87r06if76t.fsf@mid.deneb.enyo.de> <876c222f-0c90-44c7-ba3b-d5f1f5280cf7@oracle.com> <87h66qjswm.fsf@mid.deneb.enyo.de> Message-ID: On 12/26/2024 8:44 AM, Florian Weimer wrote: > * Brian Goetz: > >> The `opens` clause of a module descriptor indeed can be qualified, just >> as the exports clause can: >> >> ModuleDirective: >> ??? requires {RequiresModifier} ModuleName ; >> ??? exports PackageName [to ModuleName {, ModuleName}] ; >> ??? opens PackageName [to ModuleName {, ModuleName}] ; >> ??? uses TypeName ; >> ??? provides TypeName with TypeName {, TypeName} ; > > I think the limitation here is that PackageName cannot be *. The framework owner has a choice about what they recommend to users: - Tell users to make their modules `open`, so that all packages are open for deep reflective access to everyone, including the framework. Easy. - Tell users to open individual packages (or perhaps all of them, one by one) to a module belonging to the framework. That framework module can then use Module.addOpens(String,Module) to further open the packages to other modules in the framework. That is, openness is not transitive by default, but can be made transitive very easily. Alex From anhmdq at gmail.com Tue Jan 7 05:30:41 2025 From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=) Date: Tue, 7 Jan 2025 12:30:41 +0700 Subject: Explicit captures in lambda expression Message-ID: Hi, A feature I missed from C++ is explicit captures in lambda expressions and from recent events I think that it may be a valuable feature to have in Java. JEP-8341785[1] proposes treating loop variables as final inside the loop body, the main motivation is to allow their usage in lambda expressions inside the loop body. However, it seems to be withdrawn due to the concern of making an exception. I believe explicit captures would remove the condition that the variable being captured needs to be effectively final, resolving the motivation of JEP-8341785 and many other cases. JDK-8347047[2] is a bug caused by the implicit capture of the this reference inside a lambda, which leads to the object never being reclaimed by the garbage collector, the thing we actually want to capture there is the result of the method call this.address(). In this case, implicit captures is very error-prone and it would be better if we can explicitly declare what we want to capture instead to avoid accidentally capturing unwanted variables. As a result, I propose that: - A lambda expression can optionally have a captures, if that is the case, all the variables being captured by the lambda expression need to be declared inside it. - We can capture an effectively final variable without giving it another name, but for the others, to avoid confusion, another name for the variable is needed. E.g, suppose a, b are effectively final variables and x, y are not: () -> a; // Allowed, implicit capture of a []() -> a; // Disallowed, a is not captured and hence not defined here [a]() -> a; // Allowed, explicit capture of a [a, b]() -> a + b; // Allowed, capture 2 variables () -> x; // Disallowed, cannot implicitly capture non-effectively-final variable [x]() -> x; // Disallowed, capture a non-effectively-final without reassignment [t = x]() -> x; // Disallowed, x is not defined here [t = x]() -> t; // Allowed, x is captured and assigned to the variable t inside the lambda [t = this.address()]() -> t; // Maybe? Cheers, Quan Anh [1]: https://openjdk.org/jeps/8341785 [2]: https://bugs.openjdk.org/projects/JDK/issues/JDK-8347047 -------------- next part -------------- An HTML attachment was scrubbed... URL: From anhmdq at gmail.com Tue Jan 7 05:46:25 2025 From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=) Date: Tue, 7 Jan 2025 12:46:25 +0700 Subject: Explicit captures in lambda expression In-Reply-To: References: Message-ID: To add more context regarding JDK-8347047, even without the core lib bug, the method is easily misused. The method in consideration looks like this: MemorySegment MemorySegment::reinterpret(long size, Consumer cleanup) `cleanup` is triggered when the returned segment is closed, which for some kind of MemorySegment, is at the time the old MemorySegment instance (this) and the new MemorySegment instance (the returned segment) are garbage-collected. As a result, `cleanup` must not reference the old segment instance. It is given a freshly created MemorySegment instance and must use it. However, it is easy to mistakenly use the old instance instead: MemorySegment oldMs; oldMs.reinterpret(size, ms -> free(oldMs)); While it should be: oldMs.reinterpret(size, ms -> free(ms)); With explicit captures, it is easy to see if oldMs is mistakenly captured as this would not compiled: oldMs.reinterpret(size, [](ms) -> free(oldMs)); Cheers, Quan Anh On Tue, 7 Jan 2025 at 12:30, Qu?n Anh Mai wrote: > Hi, > > A feature I missed from C++ is explicit captures in lambda expressions and > from recent events I think that it may be a valuable feature to have in > Java. > > JEP-8341785[1] proposes treating loop variables as final inside the loop > body, the main motivation is to allow their usage in lambda expressions > inside the loop body. However, it seems to be withdrawn due to the concern > of making an exception. I believe explicit captures would remove the > condition that the variable being captured needs to be effectively final, > resolving the motivation of JEP-8341785 and many other cases. > > JDK-8347047[2] is a bug caused by the implicit capture of the this > reference inside a lambda, which leads to the object never being reclaimed > by the garbage collector, the thing we actually want to capture there is > the result of the method call this.address(). In this case, implicit > captures is very error-prone and it would be better if we can explicitly > declare what we want to capture instead to avoid accidentally capturing > unwanted variables. > > As a result, I propose that: > > - A lambda expression can optionally have a captures, if that is the case, > all the variables being captured by the lambda expression need to be > declared inside it. > - We can capture an effectively final variable without giving it another > name, but for the others, to avoid confusion, another name for the variable > is needed. > > E.g, suppose a, b are effectively final variables and x, y are not: > > () -> a; // Allowed, implicit capture of a > []() -> a; // Disallowed, a is not captured and hence not defined here > [a]() -> a; // Allowed, explicit capture of a > [a, b]() -> a + b; // Allowed, capture 2 variables > () -> x; // Disallowed, cannot implicitly capture non-effectively-final > variable > [x]() -> x; // Disallowed, capture a non-effectively-final without > reassignment > [t = x]() -> x; // Disallowed, x is not defined here > [t = x]() -> t; // Allowed, x is captured and assigned to the variable t > inside the lambda > [t = this.address()]() -> t; // Maybe? > > Cheers, > Quan Anh > > [1]: https://openjdk.org/jeps/8341785 > [2]: https://bugs.openjdk.org/projects/JDK/issues/JDK-8347047 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.kelemen85 at gmail.com Tue Jan 7 12:31:43 2025 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Tue, 7 Jan 2025 13:31:43 +0100 Subject: Explicit captures in lambda expression In-Reply-To: References: Message-ID: I like this idea, because I run into bugs of accidentally capturing "this" so many times, and the least of the problems when this causes a crash (like serialization issues), but sometimes it "just" creates a potentially huge unwanted memory retention. The workaround of moving the lambda declaration into a separate static method is very-very tedious. I do not however care so much about non-final capture (I'm not sure if it should even be allowed). What - in my opinion - the lambda capture rule should be is that the variable can be captured if it is definitely assigned before the lambda, and definitely not assigned after the lambda. Also, I don't think `[t = x]` is needed, I think that part just complicates the language with very little gain. Just allowing an explicit variable name capture list should be enough. Attila Qu?n Anh Mai ezt ?rta (id?pont: 2025. jan. 7., K, 7:17): > To add more context regarding JDK-8347047, even without the core lib bug, > the method is easily misused. The method in consideration looks like this: > > MemorySegment MemorySegment::reinterpret(long size, > Consumer cleanup) > > `cleanup` is triggered when the returned segment is closed, which for some > kind of MemorySegment, is at the time the old MemorySegment instance (this) > and the new MemorySegment instance (the returned segment) are > garbage-collected. As a result, `cleanup` must not reference the old > segment instance. It is given a freshly created MemorySegment instance and > must use it. However, it is easy to mistakenly use the old instance instead: > > MemorySegment oldMs; > oldMs.reinterpret(size, ms -> free(oldMs)); > > While it should be: > > oldMs.reinterpret(size, ms -> free(ms)); > > With explicit captures, it is easy to see if oldMs is mistakenly captured > as this would not compiled: > > oldMs.reinterpret(size, [](ms) -> free(oldMs)); > > Cheers, > Quan Anh > > On Tue, 7 Jan 2025 at 12:30, Qu?n Anh Mai wrote: > >> Hi, >> >> A feature I missed from C++ is explicit captures in lambda expressions >> and from recent events I think that it may be a valuable feature to have in >> Java. >> >> JEP-8341785[1] proposes treating loop variables as final inside the loop >> body, the main motivation is to allow their usage in lambda expressions >> inside the loop body. However, it seems to be withdrawn due to the concern >> of making an exception. I believe explicit captures would remove the >> condition that the variable being captured needs to be effectively final, >> resolving the motivation of JEP-8341785 and many other cases. >> >> JDK-8347047[2] is a bug caused by the implicit capture of the this >> reference inside a lambda, which leads to the object never being reclaimed >> by the garbage collector, the thing we actually want to capture there is >> the result of the method call this.address(). In this case, implicit >> captures is very error-prone and it would be better if we can explicitly >> declare what we want to capture instead to avoid accidentally capturing >> unwanted variables. >> >> As a result, I propose that: >> >> - A lambda expression can optionally have a captures, if that is the >> case, all the variables being captured by the lambda expression need to be >> declared inside it. >> - We can capture an effectively final variable without giving it another >> name, but for the others, to avoid confusion, another name for the variable >> is needed. >> >> E.g, suppose a, b are effectively final variables and x, y are not: >> >> () -> a; // Allowed, implicit capture of a >> []() -> a; // Disallowed, a is not captured and hence not defined here >> [a]() -> a; // Allowed, explicit capture of a >> [a, b]() -> a + b; // Allowed, capture 2 variables >> () -> x; // Disallowed, cannot implicitly capture non-effectively-final >> variable >> [x]() -> x; // Disallowed, capture a non-effectively-final without >> reassignment >> [t = x]() -> x; // Disallowed, x is not defined here >> [t = x]() -> t; // Allowed, x is captured and assigned to the variable t >> inside the lambda >> [t = this.address()]() -> t; // Maybe? >> >> Cheers, >> Quan Anh >> >> [1]: https://openjdk.org/jeps/8341785 >> [2]: https://bugs.openjdk.org/projects/JDK/issues/JDK-8347047 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robbepincket at live.be Tue Jan 7 13:58:07 2025 From: robbepincket at live.be (Robbe Pincket) Date: Tue, 7 Jan 2025 13:58:07 +0000 Subject: Explicit captures in lambda expression In-Reply-To: References: Message-ID: > the lambda capture rule should be is that the variable can be captured if it is definitely assigned before the lambda, and definitely not assigned after the lambda. I'm very confused by what you mean. A lambda can't "unassign" a variable. So I don't see in what cases a variable can be DA before the labmda and definietely unassigned afterwards (ignoring unreachable code in `if(false)` blocks) Greetings Robbe Pincket ________________________________ Van: amber-dev namens Attila Kelemen Verzonden: dinsdag 7 januari 2025 13:31 Aan: Qu?n Anh Mai CC: amber-dev at openjdk.org Onderwerp: Re: Explicit captures in lambda expression I like this idea, because I run into bugs of accidentally capturing "this" so many times, and the least of the problems when this causes a crash (like serialization issues), but sometimes it "just" creates a potentially huge unwanted memory retention. The workaround of moving the lambda declaration into a separate static method is very-very tedious. I do not however care so much about non-final capture (I'm not sure if it should even be allowed). What - in my opinion - the lambda capture rule should be is that the variable can be captured if it is definitely assigned before the lambda, and definitely not assigned after the lambda. Also, I don't think `[t = x]` is needed, I think that part just complicates the language with very little gain. Just allowing an explicit variable name capture list should be enough. Attila Qu?n Anh Mai > ezt ?rta (id?pont: 2025. jan. 7., K, 7:17): To add more context regarding JDK-8347047, even without the core lib bug, the method is easily misused. The method in consideration looks like this: MemorySegment MemorySegment::reinterpret(long size, Consumer cleanup) `cleanup` is triggered when the returned segment is closed, which for some kind of MemorySegment, is at the time the old MemorySegment instance (this) and the new MemorySegment instance (the returned segment) are garbage-collected. As a result, `cleanup` must not reference the old segment instance. It is given a freshly created MemorySegment instance and must use it. However, it is easy to mistakenly use the old instance instead: MemorySegment oldMs; oldMs.reinterpret(size, ms -> free(oldMs)); While it should be: oldMs.reinterpret(size, ms -> free(ms)); With explicit captures, it is easy to see if oldMs is mistakenly captured as this would not compiled: oldMs.reinterpret(size, [](ms) -> free(oldMs)); Cheers, Quan Anh On Tue, 7 Jan 2025 at 12:30, Qu?n Anh Mai > wrote: Hi, A feature I missed from C++ is explicit captures in lambda expressions and from recent events I think that it may be a valuable feature to have in Java. JEP-8341785[1] proposes treating loop variables as final inside the loop body, the main motivation is to allow their usage in lambda expressions inside the loop body. However, it seems to be withdrawn due to the concern of making an exception. I believe explicit captures would remove the condition that the variable being captured needs to be effectively final, resolving the motivation of JEP-8341785 and many other cases. JDK-8347047[2] is a bug caused by the implicit capture of the this reference inside a lambda, which leads to the object never being reclaimed by the garbage collector, the thing we actually want to capture there is the result of the method call this.address(). In this case, implicit captures is very error-prone and it would be better if we can explicitly declare what we want to capture instead to avoid accidentally capturing unwanted variables. As a result, I propose that: - A lambda expression can optionally have a captures, if that is the case, all the variables being captured by the lambda expression need to be declared inside it. - We can capture an effectively final variable without giving it another name, but for the others, to avoid confusion, another name for the variable is needed. E.g, suppose a, b are effectively final variables and x, y are not: () -> a; // Allowed, implicit capture of a []() -> a; // Disallowed, a is not captured and hence not defined here [a]() -> a; // Allowed, explicit capture of a [a, b]() -> a + b; // Allowed, capture 2 variables () -> x; // Disallowed, cannot implicitly capture non-effectively-final variable [x]() -> x; // Disallowed, capture a non-effectively-final without reassignment [t = x]() -> x; // Disallowed, x is not defined here [t = x]() -> t; // Allowed, x is captured and assigned to the variable t inside the lambda [t = this.address()]() -> t; // Maybe? Cheers, Quan Anh [1]: https://openjdk.org/jeps/8341785 [2]: https://bugs.openjdk.org/projects/JDK/issues/JDK-8347047 -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.kelemen85 at gmail.com Tue Jan 7 15:53:23 2025 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Tue, 7 Jan 2025 16:53:23 +0100 Subject: Explicit captures in lambda expression In-Reply-To: References: Message-ID: I didn't mean for the lambda to unassign the variable, I was just lazy to write it out exactly: I meant that the variable is DU after lambda if we assume that the variable is DU at the point of capturing (basically we pretend that the variable is DU even though it is actually DA). Consider this code (doesn't compile, but I think it should). int x = 5; if (test) x = 6; new Thread(() -> { System.out.println("Hello: " + x) }).start(); I don't really see why this shouldn't compile. Robbe Pincket ezt ?rta (id?pont: 2025. jan. 7., K, 14:58): > > the lambda capture rule should be is that the variable can be captured > if it is definitely assigned before the lambda, and definitely not assigned > after the lambda. > > I'm very confused by what you mean. A lambda can't "unassign" a variable. > So I don't see in what cases a variable can be DA before the labmda and > definietely unassigned afterwards (ignoring unreachable code in `if(false)` > blocks) > > Greetings > Robbe Pincket > > ------------------------------ > *Van:* amber-dev namens Attila Kelemen < > attila.kelemen85 at gmail.com> > *Verzonden:* dinsdag 7 januari 2025 13:31 > *Aan:* Qu?n Anh Mai > *CC:* amber-dev at openjdk.org > *Onderwerp:* Re: Explicit captures in lambda expression > > I like this idea, because I run into bugs of accidentally capturing "this" > so many times, and the least of the problems when this causes a crash (like > serialization issues), but sometimes it "just" creates a potentially huge > unwanted memory retention. The workaround of moving the lambda declaration > into a separate static method is very-very tedious. > > I do not however care so much about non-final capture (I'm not sure if it > should even be allowed). What - in my opinion - the lambda capture rule > should be is that the variable can be captured if it is definitely assigned > before the lambda, and definitely not assigned after the lambda. > > Also, I don't think `[t = x]` is needed, I think that part just > complicates the language with very little gain. Just allowing an explicit > variable name capture list should be enough. > > Attila > > Qu?n Anh Mai ezt ?rta (id?pont: 2025. jan. 7., K, > 7:17): > > To add more context regarding JDK-8347047, even without the core lib bug, > the method is easily misused. The method in consideration looks like this: > > MemorySegment MemorySegment::reinterpret(long size, > Consumer cleanup) > > `cleanup` is triggered when the returned segment is closed, which for some > kind of MemorySegment, is at the time the old MemorySegment instance (this) > and the new MemorySegment instance (the returned segment) are > garbage-collected. As a result, `cleanup` must not reference the old > segment instance. It is given a freshly created MemorySegment instance and > must use it. However, it is easy to mistakenly use the old instance instead: > > MemorySegment oldMs; > oldMs.reinterpret(size, ms -> free(oldMs)); > > While it should be: > > oldMs.reinterpret(size, ms -> free(ms)); > > With explicit captures, it is easy to see if oldMs is mistakenly captured > as this would not compiled: > > oldMs.reinterpret(size, [](ms) -> free(oldMs)); > > Cheers, > Quan Anh > > On Tue, 7 Jan 2025 at 12:30, Qu?n Anh Mai wrote: > > Hi, > > A feature I missed from C++ is explicit captures in lambda expressions and > from recent events I think that it may be a valuable feature to have in > Java. > > JEP-8341785[1] proposes treating loop variables as final inside the loop > body, the main motivation is to allow their usage in lambda expressions > inside the loop body. However, it seems to be withdrawn due to the concern > of making an exception. I believe explicit captures would remove the > condition that the variable being captured needs to be effectively final, > resolving the motivation of JEP-8341785 and many other cases. > > JDK-8347047[2] is a bug caused by the implicit capture of the this > reference inside a lambda, which leads to the object never being reclaimed > by the garbage collector, the thing we actually want to capture there is > the result of the method call this.address(). In this case, implicit > captures is very error-prone and it would be better if we can explicitly > declare what we want to capture instead to avoid accidentally capturing > unwanted variables. > > As a result, I propose that: > > - A lambda expression can optionally have a captures, if that is the case, > all the variables being captured by the lambda expression need to be > declared inside it. > - We can capture an effectively final variable without giving it another > name, but for the others, to avoid confusion, another name for the variable > is needed. > > E.g, suppose a, b are effectively final variables and x, y are not: > > () -> a; // Allowed, implicit capture of a > []() -> a; // Disallowed, a is not captured and hence not defined here > [a]() -> a; // Allowed, explicit capture of a > [a, b]() -> a + b; // Allowed, capture 2 variables > () -> x; // Disallowed, cannot implicitly capture non-effectively-final > variable > [x]() -> x; // Disallowed, capture a non-effectively-final without > reassignment > [t = x]() -> x; // Disallowed, x is not defined here > [t = x]() -> t; // Allowed, x is captured and assigned to the variable t > inside the lambda > [t = this.address()]() -> t; // Maybe? > > Cheers, > Quan Anh > > [1]: https://openjdk.org/jeps/8341785 > [2]: https://bugs.openjdk.org/projects/JDK/issues/JDK-8347047 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Tue Jan 7 16:30:03 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 7 Jan 2025 10:30:03 -0600 Subject: Explicit captures in lambda expression In-Reply-To: References: Message-ID: On Tue, Jan 7, 2025 at 9:54?AM Attila Kelemen wrote: > I didn't mean for the lambda to unassign the variable, I was just lazy to > write it out exactly: I meant that the variable is DU after lambda if we > assume that the variable is DU at the point of capturing (basically we > pretend that the variable is DU even though it is actually DA). Consider > this code (doesn't compile, but I think it should). > > int x = 5; > if (test) x = 6; > new Thread(() -> { System.out.println("Hello: " + x) }).start(); > > I don't really see why this shouldn't compile. > In the for() loop discussion, we used the phrase "not reassigned" for this concept. That thread ("JDK-8300691 - final variables in for loop headers should accept updates") has a bunch of discussion about the idea. One wrinkle is that properly defining "not reassigned" requires properly defining "before" and "after", and for() loops complicate that definition. For example if you have this: for (int i = 1; i <= 3; i++) { Runnable r = () -> System.out.println(i); // allow this? } The "i++" happens "after" the capture - assuming your definition of "after" is based on control flow rather than lexical position - which means we'd need a special exception for it, etc. John Rose had some relevant thoughts/discussion here (re: "final shadowing"): https://mail.openjdk.org/pipermail/amber-dev/2024-October/008996.html -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at mccue.dev Sun Jan 19 17:24:10 2025 From: ethan at mccue.dev (Ethan McCue) Date: Sun, 19 Jan 2025 12:24:10 -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: Following up to say: this will take more effort than I thought it would. New years turned out to be a smidge optimistic. 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 kfogel at dawsoncollege.qc.ca Sun Jan 19 17:55:34 2025 From: kfogel at dawsoncollege.qc.ca (Kenneth Fogel) Date: Sun, 19 Jan 2025 17:55:34 +0000 Subject: Flogging a dead horse - reading a number Message-ID: Hi, I have started a new course this past week, a first level Java course. Once we get past "Hello Moose" (in Canada we prefer this to Hello World) I present a simple program that calculates loan payments. Then I present an interactive version where I am forced to write: var loan = Double.parseDouble(readln("Loan: ")); var interest = Double.parseDouble(readln("Interest: ")); var term = Double.parseDouble(readln("Term: ")); Its all going well until I must describe what Double.parseDouble is. I do not need a read for each numeric type. A read for doubles is all I think is necessary and then I could write: var loan = (readNum("Loan: ")); // loan is a double or if I need an integer: var numberOfCarrots = (int)readNum("How many carrots do you need? "); Heck, if I were greedy, I'd ask that if you cast a readln this results in numeric input: var loan = (double) readln("Loan: ")); // Just like Python But I'm not that greedy, today. Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun Jan 19 18:15:42 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 19 Jan 2025 19:15:42 +0100 (CET) Subject: Flogging a dead horse - reading a number In-Reply-To: References: Message-ID: <1913325995.68700782.1737310542197.JavaMail.zimbra@univ-eiffel.fr> > From: "Kenneth Fogel" > To: "amber-dev" > Sent: Sunday, January 19, 2025 6:55:34 PM > Subject: Flogging a dead horse - reading a number > Hi, Hello, > I have started a new course this past week, a first level Java course. Once we > get past ?Hello Moose? (in Canada we prefer this to Hello World) I present a > simple program that calculates loan payments. Then I present an interactive > version where I am forced to write: > var loan = Double.parseDouble(readln("Loan: ")); > var interest = Double.parseDouble(readln("Interest: ")); > var term = Double.parseDouble(readln("Term: ")); > Its all going well until I must describe what Double.parseDouble is. > I do not need a read for each numeric type. A read for doubles is all I think is > necessary and then I could write: > var loan = (readNum("Loan: ")); // loan is a double > or if I need an integer: > var numberOfCarrots = (int)readNum(?How many carrots do you need? ?); > Heck, if I were greedy, I?d ask that if you cast a readln this results in > numeric input: > var loan = (double) readln("Loan: ")); // Just like Python Java is not a dynamically typed language, so no ! That's said, you are free to provide a library for your students. In my case, with my students, we first go from readln/println to IO.readln()/IO.println() and then we add Integer.parseInt() and Double.parseDouble(), so Double.parseDouble() is not alien at the time it is introduced. > But I?m not that greedy, today. > Ken regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.1993grajales at gmail.com Sun Jan 19 23:28:58 2025 From: david.1993grajales at gmail.com (david Grajales) Date: Sun, 19 Jan 2025 18:28:58 -0500 Subject: Moving new IO to java lang and implicitly import all static methods there for simple source files Message-ID: Hi Amber Team, I?ve been thinking about a couple of ideas that might make Java even more beginner-friendly and for the next iteration of JEP 495 1) Move java.io.IO into java.lang. This would save developers from having to import java.io explicitly, especially as projects grow. It?s a small change that could streamline things right from the start. I suspect the new println() and readln() methods are going to be heavily used, it would be weird these methods need an import once the public class is set while System.out.* do not. 2) Implicitly import static methods in java.lang. Common methods like Double.parseDouble(), Integer.parseInt(), Math.sqrt() and so on are super handy, but explaining static methods can feel like a detour for beginners learning algorithms or basic concepts. Implicit imports could make Java easier to pick up while still allowing the traditional Class.method() style. This would also make java more similar to other languages such as Python and JS, helping java to keep competent as a first language. For example, a simple script could look like this: void main() { var doubleStr = readln("enter a double number"); var doubleNum = parseDouble(doubleStr); println(sqrt(doubleNum)); } I get that static imports can sometimes cause ambiguity, but in small, simple scripts or beginner projects, it?s unlikely people would use alternative libraries for functionality already in java.lang. This change could make Java feel more accessible without breaking anything (i guess, please correct me if i am mistaken) I hope these not to be hard to implement or to be full of inconveniences, I understand things are often more complex than what meets the eye. Best regards and wishes. I have been playing with primitive pattern matching in switch and I am very excited about it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfogel at dawsoncollege.qc.ca Mon Jan 20 14:34:34 2025 From: kfogel at dawsoncollege.qc.ca (Kenneth Fogel) Date: Mon, 20 Jan 2025 14:34:34 +0000 Subject: Flogging a dead horse - reading a number In-Reply-To: <1913325995.68700782.1737310542197.JavaMail.zimbra@univ-eiffel.fr> References: <1913325995.68700782.1737310542197.JavaMail.zimbra@univ-eiffel.fr> Message-ID: I don?t think my suggestions break type safety. Have a read for doubles or allow transforming Strings to a number via casting still maintains type safety. Or, I could suggest: double value = readln(?Give me a value?); that implies that the String should be converted because of the declared type on the LHS. This would also restrict var as it depends on the type on the RHS. Delusionally yours, Ken ________________________________ From: Remi Forax Sent: Sunday, January 19, 2025 1:15:42 PM To: Kenneth Fogel Cc: amber-dev Subject: Re: Flogging a dead horse - reading a number ________________________________ From: "Kenneth Fogel" To: "amber-dev" Sent: Sunday, January 19, 2025 6:55:34 PM Subject: Flogging a dead horse - reading a number Hi, Hello, I have started a new course this past week, a first level Java course. Once we get past ?Hello Moose? (in Canada we prefer this to Hello World) I present a simple program that calculates loan payments. Then I present an interactive version where I am forced to write: var loan = Double.parseDouble(readln("Loan: ")); var interest = Double.parseDouble(readln("Interest: ")); var term = Double.parseDouble(readln("Term: ")); Its all going well until I must describe what Double.parseDouble is. I do not need a read for each numeric type. A read for doubles is all I think is necessary and then I could write: var loan = (readNum("Loan: ")); // loan is a double or if I need an integer: var numberOfCarrots = (int)readNum(?How many carrots do you need? ?); Heck, if I were greedy, I?d ask that if you cast a readln this results in numeric input: var loan = (double) readln("Loan: ")); // Just like Python Java is not a dynamically typed language, so no ! That's said, you are free to provide a library for your students. In my case, with my students, we first go from readln/println to IO.readln()/IO.println() and then we add Integer.parseInt() and Double.parseDouble(), so Double.parseDouble() is not alien at the time it is introduced. But I?m not that greedy, today. Ken regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From pyltsinm at gmail.com Tue Jan 21 12:47:07 2025 From: pyltsinm at gmail.com (Mikhail Pyltsin) Date: Tue, 21 Jan 2025 13:47:07 +0100 Subject: Running static main method inside abstract class, containing another main method Message-ID: Hi! I am investigating a new version of jep495 ( https://cr.openjdk.org/~gbierman/jep495/jep495-20241101/specs/simple-source-files-instance-main-methods-jls.html#jls-12.1.3 ) and came up with such an example: ```java public abstract class AbstractClass { public static void main() { System.out.println("Hello, World!"); } public void main(String[] args) { System.out.println("Hello, World! no constructor, non-static, args"); } } ``` Right now java chooses `void main(String[] args) ` because it contains an argument, but cannot create this class, because it is abstract, I have got this error: `Exception in thread "main" java.lang.InstantiationException: AbstractClass` Could you help me if this is expected? I expect that `public static void main()` will be chosen. I cannot find anything related to this in JEP except this one: `The behavior of an implementation if there is no candidate method to invoke, or if there is no suitable constructor in the initial class when invoking an instance candidate method, is beyond the scope of this specification.', but it doesn't contain this case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Tue Jan 21 13:28:05 2025 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 21 Jan 2025 13:28:05 +0000 Subject: Finalising the on-ramp feature Message-ID: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> Dear Experts, With JDK 24 preparations complete, we are now planning our work for JDK 25 and in particular the on-ramp JEP. It is our intention to *finalise* the on-ramp feature in JDK 25. We are grateful for the feedback that we have received from our expert and developer communities - thank you! - and we have been performing our own extensive in-house experiments with the preview feature. Given this, we propose that we make the following changes/simplifications to the feature when it finalizes in JDK 25. ## 1. Remove the auto-static-import feature and move the `IO` class We had proposed that the static members of a new class `IO` would automatically be imported by simple compilation units. This allows the use of the simple names `println`, `print`, `readln`, and `read`. Whilst this is very convenient, it creates a bump in the on-ramp experience when migrating a simple compilation unit to an ordinary compilation unit, which does not implicitly import these static methods. This means that when migrating we either add an explicit static import, or rewrite all the `println`, `print`, `readln` and `read` method calls to qualified calls. We have come to the conclusion that the graceful on-ramp experience is the more important goal. So, we propose in JDK 25 that (1) we drop the automatic static import of the `IO` class by simple compilation units, and (2) We move the `IO` class from package `java.io` to `java.lang`. This means that in simple compilation units calls to the `IO` methods should be qualified, i.e. `IO.println`, `IO.print`, `IO.readln` and `IO.read`. However, when migrating from a simple compilation unit to an ordinary compilation unit, no static import declaration will need to be added, nor will any of these calls need to be rewritten; the on-ramp experience is simpler. For example: ``` // Simple.java void main() { IO.println("Hello, world."); } ``` is migrated to: ``` // Ordinary.java class Ordinary { void main() { IO.println("Hello, world.?); } } ``` ## 2. Changes to the `IO` class The new `IO` class is intended to contain the most basic line-oriented I/O methods for beginners. Currently the implementation of the methods of this class are thin wrappers around their equivalents in the `Console` class. We propose in JDK 25 to decouple `IO` completely from `Console` which we think will better reflect the expectation of developers (see, for example, https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html). Thus we propose that `IO` printing and reading are based on `System.out` and `System.in`, respectively. We do not plan to add other functionality to the `IO` class, e.g. a `readInt` method, in JDK 25. We observe: 1. This JEP is not the final word on improving the on-ramp experience in Java, but merely the first step. We can continue to work on this area in future JEPs. 2. I/O and data conversion are, we believe, separate concerns and, as such, data conversion doesn't belong in a basic I/O class. Conversion, and in particular the related issues around error handling, can be considered separately, and given the auto-import of the `java.base` module, we can easily add additional utility classes in support of this in future releases. ## 3. Revise some terminology We're going to replace the term "simple compilation unit" with "**compact** compilation unit" in the spec (and replace "simple source file" with "compact source file" in the JEP text). Hopefully, "compact" is more concrete, evocative terminology (and we have used it elsewhere with records). Comments welcome! Thanks, Gavin From david.1993grajales at gmail.com Tue Jan 21 15:54:54 2025 From: david.1993grajales at gmail.com (david Grajales) Date: Tue, 21 Jan 2025 10:54:54 -0500 Subject: Finalising the on-ramp feature In-Reply-To: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> Message-ID: Hi Gavin. Hope you are doing well. I would like to suggest a last change if allowed, hoping it's not it to be not full of inconveniences. What about implicitly importing all static methods on java.lang (not sure about only for compact compilation units of a general)? that would make easier and shorter simple operations like parsing strings to any number type, use the Math package and so on, it would be still allow for Class.method() when preferred/needed without change in the source code (For example if one would want to use a concrete implementation of max()), I know there are some clarity issues (where does this method comes from?" )besides and to be honest, it's very unlikely people will use alternatives for what java lang offers in most cases unless they need very specific requirements, so further ambiguity is a less concern IMHO, far less disruptive in this regard than star imports and import module. It's a small quality of life improvement, specially for small things and students. Best regards and best wishes to all Java development team. El mar, 21 ene 2025 a la(s) 8:28?a.m., Gavin Bierman ( gavin.bierman at oracle.com) escribi?: > Dear Experts, > > With JDK 24 preparations complete, we are now planning our work for JDK 25 > and > in particular the on-ramp JEP. It is our intention to *finalise* the > on-ramp > feature in JDK 25. We are grateful for the feedback that we have received > from > our expert and developer communities - thank you! - and we have been > performing > our own extensive in-house experiments with the preview feature. Given > this, we > propose that we make the following changes/simplifications to the feature > when > it finalizes in JDK 25. > > ## 1. Remove the auto-static-import feature and move the `IO` class > > We had proposed that the static members of a new class `IO` would > automatically > be imported by simple compilation units. This allows the use of the simple > names > `println`, `print`, `readln`, and `read`. Whilst this is very convenient, > it > creates a bump in the on-ramp experience when migrating a simple > compilation > unit to an ordinary compilation unit, which does not implicitly import > these static > methods. This means that when migrating we either add an explicit static > import, > or rewrite all the `println`, `print`, `readln` and `read` method calls to > qualified calls. > > We have come to the conclusion that the graceful on-ramp experience is the > more > important goal. So, we propose in JDK 25 that (1) we drop the automatic > static > import of the `IO` class by simple compilation units, and (2) We move the > `IO` > class from package `java.io` to `java.lang`. > > This means that in simple compilation units calls to the `IO` methods > should be > qualified, i.e. `IO.println`, `IO.print`, `IO.readln` and `IO.read`. > However, > when migrating from a simple compilation unit to an ordinary compilation > unit, > no static import declaration will need to be added, nor will any of these > calls > need to be rewritten; the on-ramp experience is simpler. For example: > > ``` > // Simple.java > void main() { > IO.println("Hello, world."); > } > ``` > > is migrated to: > > ``` > // Ordinary.java > class Ordinary { > void main() { > IO.println("Hello, world.?); > } > } > ``` > > > ## 2. Changes to the `IO` class > > The new `IO` class is intended to contain the most basic line-oriented I/O > methods for beginners. > > Currently the implementation of the methods of this class are thin wrappers > around their equivalents in the `Console` class. We propose in JDK 25 to > decouple `IO` completely from `Console` which we think will better reflect > the > expectation of developers (see, for example, > https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html). > > Thus we propose that `IO` printing and reading are based on `System.out` > and > `System.in`, respectively. > > We do not plan to add other functionality to the `IO` class, e.g. a > `readInt` > method, in JDK 25. We observe: > > 1. This JEP is not the final word on improving the on-ramp experience in > Java, > but merely the first step. We can continue to work on this area in future > JEPs. > > 2. I/O and data conversion are, we believe, separate concerns and, as > such, data > conversion doesn't belong in a basic I/O class. Conversion, and in > particular > the related issues around error handling, can be considered separately, > and given the auto-import of the `java.base` module, we can easily add > additional utility classes in support of this in future releases. > > ## 3. Revise some terminology > > We're going to replace the term "simple compilation unit" with "**compact** > compilation unit" in the spec (and replace "simple source file" with > "compact > source file" in the JEP text). Hopefully, "compact" is more concrete, > evocative > terminology (and we have used it elsewhere with records). > > > Comments welcome! > > Thanks, > Gavin -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Tue Jan 21 16:04:43 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 21 Jan 2025 11:04:43 -0500 Subject: Finalising the on-ramp feature In-Reply-To: References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> Message-ID: <7a94218f-bafc-4864-abbc-b177791f1a86@oracle.com> This is an idea that we discussed and rejected (with extreme prejudice!) very early on the process.? It effectively takes every static method in java.lang (including what will probably seem like a random grab bag of things like runFinalizersOnExit) and elevates them "into the language."? (THen, it creates a perverse incentive to put MORE stuff in java.lang just to get the importing.)? This is the very opposite of what we want to achieve here. On 1/21/2025 10:54 AM, david Grajales wrote: > Hi Gavin. Hope you are doing well. > I would like to suggest a last change if allowed, hoping it's not it > to be not full of inconveniences. > > What about implicitly importing all static methods on java.lang (not > sure about only for compact compilation units of a general)? that > would make easier and shorter simple operations like parsing strings > to any number type, use the Math package and so on, it would be still > allow for Class.method() when preferred/needed without change in the > source code (For example if one would want to use a concrete > implementation of max()), I know there are some clarity issues (where > does this method comes from?" )besides and to?be honest, it's very > unlikely people will use alternatives for what java lang offers in > most cases unless they need very specific requirements, so further > ambiguity is a less concern IMHO, far less disruptive in this regard > than star imports and import module. > > It's a small quality of life improvement, specially for small things > and students. > > Best regards and best wishes to all Java development team. > > El mar, 21 ene 2025 a la(s) 8:28?a.m., Gavin Bierman > (gavin.bierman at oracle.com) escribi?: > > Dear Experts, > > With JDK 24 preparations complete, we are now planning our work > for JDK 25 and > in particular the on-ramp JEP. It is our intention to *finalise* > the on-ramp > feature in JDK 25. We are grateful for the feedback that we have > received from > our expert and developer communities - thank you! - and we have > been performing > our own extensive in-house experiments with the preview feature. > Given this, we > propose that we make the following changes/simplifications to the > feature when > it finalizes in JDK 25. > > ## 1. Remove the auto-static-import feature and move the `IO` class > > We had proposed that the static members of a new class `IO` would > automatically > be imported by simple compilation units. This allows the use of > the simple names > `println`, `print`, `readln`, and `read`. Whilst this is very > convenient, it > creates a bump in the on-ramp experience when migrating a simple > compilation > unit to an ordinary compilation unit, which does not implicitly > import these static > methods. This means that when migrating we either add an explicit > static import, > or rewrite all the `println`, `print`, `readln` and `read` method > calls to > qualified calls. > > We have come to the conclusion that the graceful on-ramp > experience is the more > important goal. So, we propose in JDK 25 that (1) we drop the > automatic static > import of the `IO` class by simple compilation units, and (2) We > move the `IO` > class from package `java.io ` to `java.lang`. > > This means that in simple compilation units calls to the `IO` > methods should be > qualified, i.e. `IO.println`, `IO.print`, `IO.readln` and > `IO.read`. However, > when migrating from a simple compilation unit to an ordinary > compilation unit, > no static import declaration will need to be added, nor will any > of these calls > need to be rewritten; the on-ramp experience is simpler. For example: > > ``` > // Simple.java > void main() { > ? ? IO.println("Hello, world."); > } > ``` > > is migrated to: > > ``` > // Ordinary.java > class Ordinary { > ? ? void main() { > ? ? ? ? IO.println("Hello, world.?); > ? ? } > } > ``` > > > ## 2. Changes to the `IO` class > > The new `IO` class is intended to contain the most basic > line-oriented I/O > methods for beginners. > > Currently the implementation of the methods of this class are thin > wrappers > around their equivalents in the `Console` class. We propose in JDK > 25 to > decouple `IO` completely from `Console` which we think will better > reflect the > expectation of developers (see, for example, > https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html). > > Thus we propose that `IO` printing and reading are based on > `System.out` and > `System.in`, respectively. > > We do not plan to add other functionality to the `IO` class, e.g. > a `readInt` > method, in JDK 25. We observe: > > 1. This JEP is not the final word on improving the on-ramp > experience in Java, > but merely the first step. We can continue to work on this area in > future > JEPs. > > 2. I/O and data conversion are, we believe, separate concerns and, > as such, data > conversion doesn't belong in a basic I/O class. Conversion, and in > particular > the related issues around error handling, can be considered > separately, > and given the auto-import of the `java.base` module, we can easily add > additional utility classes in support of this in future releases. > > ## 3. Revise some terminology > > We're going to replace the term "simple compilation unit" with > "**compact** > compilation unit" in the spec (and replace "simple source file" > with "compact > source file" in the JEP text). Hopefully, "compact" is more > concrete, evocative > terminology (and we have used it elsewhere with records). > > > Comments welcome! > > Thanks, > Gavin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.1993grajales at gmail.com Tue Jan 21 16:26:40 2025 From: david.1993grajales at gmail.com (david Grajales) Date: Tue, 21 Jan 2025 11:26:40 -0500 Subject: Finalising the on-ramp feature In-Reply-To: <7a94218f-bafc-4864-abbc-b177791f1a86@oracle.com> References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> <7a94218f-bafc-4864-abbc-b177791f1a86@oracle.com> Message-ID: Perfectly understandable. Thanks Brian. Best regards. El mar, 21 de ene de 2025, 11:04?a. m., Brian Goetz escribi?: > This is an idea that we discussed and rejected (with extreme prejudice!) > very early on the process. It effectively takes every static method in > java.lang (including what will probably seem like a random grab bag of > things like runFinalizersOnExit) and elevates them "into the language." > (THen, it creates a perverse incentive to put MORE stuff in java.lang just > to get the importing.) This is the very opposite of what we want to > achieve here. > > > On 1/21/2025 10:54 AM, david Grajales wrote: > > Hi Gavin. Hope you are doing well. > I would like to suggest a last change if allowed, hoping it's not it to be > not full of inconveniences. > > What about implicitly importing all static methods on java.lang (not sure > about only for compact compilation units of a general)? that would make > easier and shorter simple operations like parsing strings to any number > type, use the Math package and so on, it would be still allow for > Class.method() when preferred/needed without change in the source code (For > example if one would want to use a concrete implementation of max()), I > know there are some clarity issues (where does this method comes from?" > )besides and to be honest, it's very unlikely people will use alternatives > for what java lang offers in most cases unless they need very specific > requirements, so further ambiguity is a less concern IMHO, far less > disruptive in this regard than star imports and import module. > > It's a small quality of life improvement, specially for small things and > students. > > Best regards and best wishes to all Java development team. > > El mar, 21 ene 2025 a la(s) 8:28?a.m., Gavin Bierman ( > gavin.bierman at oracle.com) escribi?: > >> Dear Experts, >> >> With JDK 24 preparations complete, we are now planning our work for JDK >> 25 and >> in particular the on-ramp JEP. It is our intention to *finalise* the >> on-ramp >> feature in JDK 25. We are grateful for the feedback that we have received >> from >> our expert and developer communities - thank you! - and we have been >> performing >> our own extensive in-house experiments with the preview feature. Given >> this, we >> propose that we make the following changes/simplifications to the feature >> when >> it finalizes in JDK 25. >> >> ## 1. Remove the auto-static-import feature and move the `IO` class >> >> We had proposed that the static members of a new class `IO` would >> automatically >> be imported by simple compilation units. This allows the use of the >> simple names >> `println`, `print`, `readln`, and `read`. Whilst this is very convenient, >> it >> creates a bump in the on-ramp experience when migrating a simple >> compilation >> unit to an ordinary compilation unit, which does not implicitly import >> these static >> methods. This means that when migrating we either add an explicit static >> import, >> or rewrite all the `println`, `print`, `readln` and `read` method calls to >> qualified calls. >> >> We have come to the conclusion that the graceful on-ramp experience is >> the more >> important goal. So, we propose in JDK 25 that (1) we drop the automatic >> static >> import of the `IO` class by simple compilation units, and (2) We move the >> `IO` >> class from package `java.io` to `java.lang`. >> >> This means that in simple compilation units calls to the `IO` methods >> should be >> qualified, i.e. `IO.println`, `IO.print`, `IO.readln` and `IO.read`. >> However, >> when migrating from a simple compilation unit to an ordinary compilation >> unit, >> no static import declaration will need to be added, nor will any of these >> calls >> need to be rewritten; the on-ramp experience is simpler. For example: >> >> ``` >> // Simple.java >> void main() { >> IO.println("Hello, world."); >> } >> ``` >> >> is migrated to: >> >> ``` >> // Ordinary.java >> class Ordinary { >> void main() { >> IO.println("Hello, world.?); >> } >> } >> ``` >> >> >> ## 2. Changes to the `IO` class >> >> The new `IO` class is intended to contain the most basic line-oriented I/O >> methods for beginners. >> >> Currently the implementation of the methods of this class are thin >> wrappers >> around their equivalents in the `Console` class. We propose in JDK 25 to >> decouple `IO` completely from `Console` which we think will better >> reflect the >> expectation of developers (see, for example, >> https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html). >> >> Thus we propose that `IO` printing and reading are based on `System.out` >> and >> `System.in`, respectively. >> >> We do not plan to add other functionality to the `IO` class, e.g. a >> `readInt` >> method, in JDK 25. We observe: >> >> 1. This JEP is not the final word on improving the on-ramp experience in >> Java, >> but merely the first step. We can continue to work on this area in future >> JEPs. >> >> 2. I/O and data conversion are, we believe, separate concerns and, as >> such, data >> conversion doesn't belong in a basic I/O class. Conversion, and in >> particular >> the related issues around error handling, can be considered separately, >> and given the auto-import of the `java.base` module, we can easily add >> additional utility classes in support of this in future releases. >> >> ## 3. Revise some terminology >> >> We're going to replace the term "simple compilation unit" with >> "**compact** >> compilation unit" in the spec (and replace "simple source file" with >> "compact >> source file" in the JEP text). Hopefully, "compact" is more concrete, >> evocative >> terminology (and we have used it elsewhere with records). >> >> >> Comments welcome! >> >> Thanks, >> Gavin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at mccue.dev Tue Jan 21 17:17:32 2025 From: ethan at mccue.dev (Ethan McCue) Date: Tue, 21 Jan 2025 12:17:32 -0500 Subject: Finalising the on-ramp feature In-Reply-To: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> Message-ID: One question I have: If the implicit import module java.base; remains, what was the impetus for moving IO to java.lang? On Tue, Jan 21, 2025 at 9:55?AM Gavin Bierman wrote: > Dear Experts, > > With JDK 24 preparations complete, we are now planning our work for JDK 25 > and > in particular the on-ramp JEP. It is our intention to *finalise* the > on-ramp > feature in JDK 25. We are grateful for the feedback that we have received > from > our expert and developer communities - thank you! - and we have been > performing > our own extensive in-house experiments with the preview feature. Given > this, we > propose that we make the following changes/simplifications to the feature > when > it finalizes in JDK 25. > > ## 1. Remove the auto-static-import feature and move the `IO` class > > We had proposed that the static members of a new class `IO` would > automatically > be imported by simple compilation units. This allows the use of the simple > names > `println`, `print`, `readln`, and `read`. Whilst this is very convenient, > it > creates a bump in the on-ramp experience when migrating a simple > compilation > unit to an ordinary compilation unit, which does not implicitly import > these static > methods. This means that when migrating we either add an explicit static > import, > or rewrite all the `println`, `print`, `readln` and `read` method calls to > qualified calls. > > We have come to the conclusion that the graceful on-ramp experience is the > more > important goal. So, we propose in JDK 25 that (1) we drop the automatic > static > import of the `IO` class by simple compilation units, and (2) We move the > `IO` > class from package `java.io` to `java.lang`. > > This means that in simple compilation units calls to the `IO` methods > should be > qualified, i.e. `IO.println`, `IO.print`, `IO.readln` and `IO.read`. > However, > when migrating from a simple compilation unit to an ordinary compilation > unit, > no static import declaration will need to be added, nor will any of these > calls > need to be rewritten; the on-ramp experience is simpler. For example: > > ``` > // Simple.java > void main() { > IO.println("Hello, world."); > } > ``` > > is migrated to: > > ``` > // Ordinary.java > class Ordinary { > void main() { > IO.println("Hello, world.?); > } > } > ``` > > > ## 2. Changes to the `IO` class > > The new `IO` class is intended to contain the most basic line-oriented I/O > methods for beginners. > > Currently the implementation of the methods of this class are thin wrappers > around their equivalents in the `Console` class. We propose in JDK 25 to > decouple `IO` completely from `Console` which we think will better reflect > the > expectation of developers (see, for example, > https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html). > > Thus we propose that `IO` printing and reading are based on `System.out` > and > `System.in`, respectively. > > We do not plan to add other functionality to the `IO` class, e.g. a > `readInt` > method, in JDK 25. We observe: > > 1. This JEP is not the final word on improving the on-ramp experience in > Java, > but merely the first step. We can continue to work on this area in future > JEPs. > > 2. I/O and data conversion are, we believe, separate concerns and, as > such, data > conversion doesn't belong in a basic I/O class. Conversion, and in > particular > the related issues around error handling, can be considered separately, > and given the auto-import of the `java.base` module, we can easily add > additional utility classes in support of this in future releases. > > ## 3. Revise some terminology > > We're going to replace the term "simple compilation unit" with "**compact** > compilation unit" in the spec (and replace "simple source file" with > "compact > source file" in the JEP text). Hopefully, "compact" is more concrete, > evocative > terminology (and we have used it elsewhere with records). > > > Comments welcome! > > Thanks, > Gavin -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Tue Jan 21 17:23:15 2025 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 21 Jan 2025 12:23:15 -0500 Subject: Finalising the on-ramp feature In-Reply-To: References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> Message-ID: Consistency, and smoothing the entry to the highway. If it's in java.io, then the java.base module import picks up IO for implicit compilation units, but not for named ones, so the locution "IO.println" stops working without an explicit module import, as well as all the existing Java code out there.? By putting IO in java.lang, then `IO.x` means the same thing for all compilation units. Essentially, it is a combination of uniformity and strength-reduction from "import-static a whole bunch of things in implicit classes only" to "import one new class symbol, IO, everywhere." On 1/21/2025 12:17 PM, Ethan McCue wrote: > One question I have: If the implicit import module java.base;?remains, > what was the impetus for moving IO to java.lang? > > On Tue, Jan 21, 2025 at 9:55?AM Gavin Bierman > wrote: > > Dear Experts, > > With JDK 24 preparations complete, we are now planning our work > for JDK 25 and > in particular the on-ramp JEP. It is our intention to *finalise* > the on-ramp > feature in JDK 25. We are grateful for the feedback that we have > received from > our expert and developer communities - thank you! - and we have > been performing > our own extensive in-house experiments with the preview feature. > Given this, we > propose that we make the following changes/simplifications to the > feature when > it finalizes in JDK 25. > > ## 1. Remove the auto-static-import feature and move the `IO` class > > We had proposed that the static members of a new class `IO` would > automatically > be imported by simple compilation units. This allows the use of > the simple names > `println`, `print`, `readln`, and `read`. Whilst this is very > convenient, it > creates a bump in the on-ramp experience when migrating a simple > compilation > unit to an ordinary compilation unit, which does not implicitly > import these static > methods. This means that when migrating we either add an explicit > static import, > or rewrite all the `println`, `print`, `readln` and `read` method > calls to > qualified calls. > > We have come to the conclusion that the graceful on-ramp > experience is the more > important goal. So, we propose in JDK 25 that (1) we drop the > automatic static > import of the `IO` class by simple compilation units, and (2) We > move the `IO` > class from package `java.io ` to `java.lang`. > > This means that in simple compilation units calls to the `IO` > methods should be > qualified, i.e. `IO.println`, `IO.print`, `IO.readln` and > `IO.read`. However, > when migrating from a simple compilation unit to an ordinary > compilation unit, > no static import declaration will need to be added, nor will any > of these calls > need to be rewritten; the on-ramp experience is simpler. For example: > > ``` > // Simple.java > void main() { > ? ? IO.println("Hello, world."); > } > ``` > > is migrated to: > > ``` > // Ordinary.java > class Ordinary { > ? ? void main() { > ? ? ? ? IO.println("Hello, world.?); > ? ? } > } > ``` > > > ## 2. Changes to the `IO` class > > The new `IO` class is intended to contain the most basic > line-oriented I/O > methods for beginners. > > Currently the implementation of the methods of this class are thin > wrappers > around their equivalents in the `Console` class. We propose in JDK > 25 to > decouple `IO` completely from `Console` which we think will better > reflect the > expectation of developers (see, for example, > https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html). > > Thus we propose that `IO` printing and reading are based on > `System.out` and > `System.in`, respectively. > > We do not plan to add other functionality to the `IO` class, e.g. > a `readInt` > method, in JDK 25. We observe: > > 1. This JEP is not the final word on improving the on-ramp > experience in Java, > but merely the first step. We can continue to work on this area in > future > JEPs. > > 2. I/O and data conversion are, we believe, separate concerns and, > as such, data > conversion doesn't belong in a basic I/O class. Conversion, and in > particular > the related issues around error handling, can be considered > separately, > and given the auto-import of the `java.base` module, we can easily add > additional utility classes in support of this in future releases. > > ## 3. Revise some terminology > > We're going to replace the term "simple compilation unit" with > "**compact** > compilation unit" in the spec (and replace "simple source file" > with "compact > source file" in the JEP text). Hopefully, "compact" is more > concrete, evocative > terminology (and we have used it elsewhere with records). > > > Comments welcome! > > Thanks, > Gavin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at mccue.dev Tue Jan 21 17:53:14 2025 From: ethan at mccue.dev (Ethan McCue) Date: Tue, 21 Jan 2025 12:53:14 -0500 Subject: Finalising the on-ramp feature In-Reply-To: References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> Message-ID: I guess what I'm wrestling with is that, with an implicit import module java.base, now List.of means a different thing for implicit compilation units than for named ones. On Tue, Jan 21, 2025 at 12:23?PM Brian Goetz wrote: > Consistency, and smoothing the entry to the highway. > > If it's in java.io, then the java.base module import picks up IO for > implicit compilation units, but not for named ones, so the locution > "IO.println" stops working without an explicit module import, as well as > all the existing Java code out there. By putting IO in java.lang, then > `IO.x` means the same thing for all compilation units. > > Essentially, it is a combination of uniformity and strength-reduction from > "import-static a whole bunch of things in implicit classes only" to "import > one new class symbol, IO, everywhere." > > > On 1/21/2025 12:17 PM, Ethan McCue wrote: > > One question I have: If the implicit import module java.base; remains, > what was the impetus for moving IO to java.lang? > > On Tue, Jan 21, 2025 at 9:55?AM Gavin Bierman > wrote: > >> Dear Experts, >> >> With JDK 24 preparations complete, we are now planning our work for JDK >> 25 and >> in particular the on-ramp JEP. It is our intention to *finalise* the >> on-ramp >> feature in JDK 25. We are grateful for the feedback that we have received >> from >> our expert and developer communities - thank you! - and we have been >> performing >> our own extensive in-house experiments with the preview feature. Given >> this, we >> propose that we make the following changes/simplifications to the feature >> when >> it finalizes in JDK 25. >> >> ## 1. Remove the auto-static-import feature and move the `IO` class >> >> We had proposed that the static members of a new class `IO` would >> automatically >> be imported by simple compilation units. This allows the use of the >> simple names >> `println`, `print`, `readln`, and `read`. Whilst this is very convenient, >> it >> creates a bump in the on-ramp experience when migrating a simple >> compilation >> unit to an ordinary compilation unit, which does not implicitly import >> these static >> methods. This means that when migrating we either add an explicit static >> import, >> or rewrite all the `println`, `print`, `readln` and `read` method calls to >> qualified calls. >> >> We have come to the conclusion that the graceful on-ramp experience is >> the more >> important goal. So, we propose in JDK 25 that (1) we drop the automatic >> static >> import of the `IO` class by simple compilation units, and (2) We move the >> `IO` >> class from package `java.io` to `java.lang`. >> >> This means that in simple compilation units calls to the `IO` methods >> should be >> qualified, i.e. `IO.println`, `IO.print`, `IO.readln` and `IO.read`. >> However, >> when migrating from a simple compilation unit to an ordinary compilation >> unit, >> no static import declaration will need to be added, nor will any of these >> calls >> need to be rewritten; the on-ramp experience is simpler. For example: >> >> ``` >> // Simple.java >> void main() { >> IO.println("Hello, world."); >> } >> ``` >> >> is migrated to: >> >> ``` >> // Ordinary.java >> class Ordinary { >> void main() { >> IO.println("Hello, world.?); >> } >> } >> ``` >> >> >> ## 2. Changes to the `IO` class >> >> The new `IO` class is intended to contain the most basic line-oriented I/O >> methods for beginners. >> >> Currently the implementation of the methods of this class are thin >> wrappers >> around their equivalents in the `Console` class. We propose in JDK 25 to >> decouple `IO` completely from `Console` which we think will better >> reflect the >> expectation of developers (see, for example, >> https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html). >> >> Thus we propose that `IO` printing and reading are based on `System.out` >> and >> `System.in`, respectively. >> >> We do not plan to add other functionality to the `IO` class, e.g. a >> `readInt` >> method, in JDK 25. We observe: >> >> 1. This JEP is not the final word on improving the on-ramp experience in >> Java, >> but merely the first step. We can continue to work on this area in future >> JEPs. >> >> 2. I/O and data conversion are, we believe, separate concerns and, as >> such, data >> conversion doesn't belong in a basic I/O class. Conversion, and in >> particular >> the related issues around error handling, can be considered separately, >> and given the auto-import of the `java.base` module, we can easily add >> additional utility classes in support of this in future releases. >> >> ## 3. Revise some terminology >> >> We're going to replace the term "simple compilation unit" with >> "**compact** >> compilation unit" in the spec (and replace "simple source file" with >> "compact >> source file" in the JEP text). Hopefully, "compact" is more concrete, >> evocative >> terminology (and we have used it elsewhere with records). >> >> >> Comments welcome! >> >> Thanks, >> Gavin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin.bierman at oracle.com Tue Jan 21 19:06:46 2025 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 21 Jan 2025 19:06:46 +0000 Subject: Finalising the on-ramp feature In-Reply-To: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> Message-ID: <0AF97878-A2C7-4189-A146-57D5BC0D6005@oracle.com> [Resending with correction] # Finalising the on-ramp feature With JDK 24 preparations complete, we are now planning our work for JDK 25 and in particular the on-ramp JEP. It is our intention to *finalise* the on-ramp feature in JDK 25. We are grateful for the feedback that we have received from our expert and developer communities - thank you! - and we have been performing our own extensive in-house experiments with the preview feature. Given this, we propose that we make the following changes/simplifications to the feature when it finalizes in JDK 25. ## 1. Remove the auto-static-import feature and move the `IO` class We had proposed that the static members of a new class `IO` would automatically be imported by simple compilation units. This allows the use of the simple names `println`, `print`, and `readln`. Whilst this is very convenient, it creates a bump in the on-ramp experience when migrating a simple compilation unit to an ordinary compilation unit, which does not implicitly import these static methods. This means that when migrating we either add an explicit static import, or rewrite all the `println`, `print`, and `readln` method calls to qualified calls. We have come to the conclusion that the graceful on-ramp experience is the more important goal. So, we propose in JDK 25 that (1) we drop the automatic static import of the `IO` class by simple compilation units, and (2) We move the `IO` class from package `java.io` to `java.lang`. This means that in simple compilation units calls to the `IO` methods should be qualified, i.e. `IO.println`, `IO.print`, and `IO.readln`. However, when migrating from a simple compilation unit to an ordinary compilation unit, no static import declaration will need to be added, nor will any of these calls need to be rewritten; the on-ramp experience is simpler. For example: ``` // Simple.java void main() { IO.println("Hello, world."); } ``` is migrated to: ``` // Ordinary.java class Ordinary { void main() { IO.println("Hello, world.?); } } ``` ## 2. Changes to the `IO` class The new `IO` class is intended to contain the most basic line-oriented I/O methods for beginners. Currently the implementation of the methods of this class are thin wrappers around their equivalents in the `Console` class. We propose in JDK 25 to decouple `IO` completely from `Console` which we think will better reflect the expectation of developers (see, for example, https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html). Thus we propose that `IO` printing and reading are based on `System.out` and `System.in`, respectively. We do not plan to add other functionality to the `IO` class, e.g. a `readInt` method, in JDK 25. We observe: 1. This JEP is not the final word on improving the on-ramp experience in Java, but merely the first step. We can continue to work on this area in future JEPs. 2. I/O and data conversion are, we believe, separate concerns and, as such, data conversion doesn't belong in a basic I/O class. Conversion, and in particular the related issues around error handling, can be considered separately, and given the auto-import of the `java.base` module, we can easily add additional utility classes in support of this in future releases. ## 3. Revise some terminology We're going to replace the term "simple compilation unit" with "**compact** compilation unit" in the spec (and replace "simple source file" with "compact source file" in the JEP text). Hopefully, "compact" is more concrete, evocative terminology (and we have used it elsewhere with records). Comments welcome! Thanks, Gavin From gavin.bierman at oracle.com Tue Jan 21 19:07:51 2025 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 21 Jan 2025 19:07:51 +0000 Subject: Finalising the on-ramp feature In-Reply-To: <9f592295-2de8-471d-82f9-6cb3e1e33026@gmail.com> References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> <9f592295-2de8-471d-82f9-6cb3e1e33026@gmail.com> Message-ID: > On 21 Jan 2025, at 18:55, Cay Horstmann wrote: > > +1 > > But what is IO.read? A typo! Thanks Cay - resent with correction. Many Thanks, Gavin From davidalayachew at gmail.com Tue Jan 21 19:32:15 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 21 Jan 2025 14:32:15 -0500 Subject: Finalising the on-ramp feature In-Reply-To: References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> Message-ID: How are they different? On Tue, Jan 21, 2025, 12:53?PM Ethan McCue wrote: > I guess what I'm wrestling with is that, with an implicit import module > java.base, now List.of means a different thing for implicit compilation > units than for named ones. > > On Tue, Jan 21, 2025 at 12:23?PM Brian Goetz > wrote: > >> Consistency, and smoothing the entry to the highway. >> >> If it's in java.io, then the java.base module import picks up IO for >> implicit compilation units, but not for named ones, so the locution >> "IO.println" stops working without an explicit module import, as well as >> all the existing Java code out there. By putting IO in java.lang, then >> `IO.x` means the same thing for all compilation units. >> >> Essentially, it is a combination of uniformity and strength-reduction >> from "import-static a whole bunch of things in implicit classes only" to >> "import one new class symbol, IO, everywhere." >> >> >> On 1/21/2025 12:17 PM, Ethan McCue wrote: >> >> One question I have: If the implicit import module java.base; remains, >> what was the impetus for moving IO to java.lang? >> >> On Tue, Jan 21, 2025 at 9:55?AM Gavin Bierman >> wrote: >> >>> Dear Experts, >>> >>> With JDK 24 preparations complete, we are now planning our work for JDK >>> 25 and >>> in particular the on-ramp JEP. It is our intention to *finalise* the >>> on-ramp >>> feature in JDK 25. We are grateful for the feedback that we have >>> received from >>> our expert and developer communities - thank you! - and we have been >>> performing >>> our own extensive in-house experiments with the preview feature. Given >>> this, we >>> propose that we make the following changes/simplifications to the >>> feature when >>> it finalizes in JDK 25. >>> >>> ## 1. Remove the auto-static-import feature and move the `IO` class >>> >>> We had proposed that the static members of a new class `IO` would >>> automatically >>> be imported by simple compilation units. This allows the use of the >>> simple names >>> `println`, `print`, `readln`, and `read`. Whilst this is very >>> convenient, it >>> creates a bump in the on-ramp experience when migrating a simple >>> compilation >>> unit to an ordinary compilation unit, which does not implicitly import >>> these static >>> methods. This means that when migrating we either add an explicit static >>> import, >>> or rewrite all the `println`, `print`, `readln` and `read` method calls >>> to >>> qualified calls. >>> >>> We have come to the conclusion that the graceful on-ramp experience is >>> the more >>> important goal. So, we propose in JDK 25 that (1) we drop the automatic >>> static >>> import of the `IO` class by simple compilation units, and (2) We move >>> the `IO` >>> class from package `java.io` to `java.lang`. >>> >>> This means that in simple compilation units calls to the `IO` methods >>> should be >>> qualified, i.e. `IO.println`, `IO.print`, `IO.readln` and `IO.read`. >>> However, >>> when migrating from a simple compilation unit to an ordinary compilation >>> unit, >>> no static import declaration will need to be added, nor will any of >>> these calls >>> need to be rewritten; the on-ramp experience is simpler. For example: >>> >>> ``` >>> // Simple.java >>> void main() { >>> IO.println("Hello, world."); >>> } >>> ``` >>> >>> is migrated to: >>> >>> ``` >>> // Ordinary.java >>> class Ordinary { >>> void main() { >>> IO.println("Hello, world.?); >>> } >>> } >>> ``` >>> >>> >>> ## 2. Changes to the `IO` class >>> >>> The new `IO` class is intended to contain the most basic line-oriented >>> I/O >>> methods for beginners. >>> >>> Currently the implementation of the methods of this class are thin >>> wrappers >>> around their equivalents in the `Console` class. We propose in JDK 25 to >>> decouple `IO` completely from `Console` which we think will better >>> reflect the >>> expectation of developers (see, for example, >>> https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html >>> ). >>> >>> Thus we propose that `IO` printing and reading are based on `System.out` >>> and >>> `System.in`, respectively. >>> >>> We do not plan to add other functionality to the `IO` class, e.g. a >>> `readInt` >>> method, in JDK 25. We observe: >>> >>> 1. This JEP is not the final word on improving the on-ramp experience in >>> Java, >>> but merely the first step. We can continue to work on this area in future >>> JEPs. >>> >>> 2. I/O and data conversion are, we believe, separate concerns and, as >>> such, data >>> conversion doesn't belong in a basic I/O class. Conversion, and in >>> particular >>> the related issues around error handling, can be considered separately, >>> and given the auto-import of the `java.base` module, we can easily add >>> additional utility classes in support of this in future releases. >>> >>> ## 3. Revise some terminology >>> >>> We're going to replace the term "simple compilation unit" with >>> "**compact** >>> compilation unit" in the spec (and replace "simple source file" with >>> "compact >>> source file" in the JEP text). Hopefully, "compact" is more concrete, >>> evocative >>> terminology (and we have used it elsewhere with records). >>> >>> >>> Comments welcome! >>> >>> Thanks, >>> Gavin >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Tue Jan 21 20:06:30 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 21 Jan 2025 21:06:30 +0100 (CET) Subject: Finalising the on-ramp feature In-Reply-To: <0AF97878-A2C7-4189-A146-57D5BC0D6005@oracle.com> References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> <0AF97878-A2C7-4189-A146-57D5BC0D6005@oracle.com> Message-ID: <1065901796.71915473.1737489990475.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Gavin Bierman" > To: "amber-spec-experts" > Cc: "amber-dev" > Sent: Tuesday, January 21, 2025 8:06:46 PM > Subject: Re: Finalising the on-ramp feature > [Resending with correction] > > # Finalising the on-ramp feature > > With JDK 24 preparations complete, we are now planning our work for JDK 25 and > in particular the on-ramp JEP. It is our intention to *finalise* the on-ramp > feature in JDK 25. We are grateful for the feedback that we have received from > our expert and developer communities - thank you! - and we have been performing > our own extensive in-house experiments with the preview feature. Given this, we > propose that we make the following changes/simplifications to the feature when > it finalizes in JDK 25. > [...] > > ## 2. Changes to the `IO` class > > The new `IO` class is intended to contain the most basic line-oriented I/O > methods for beginners. > > Currently the implementation of the methods of this class are thin wrappers > around their equivalents in the `Console` class. We propose in JDK 25 to > decouple `IO` completely from `Console` which we think will better reflect the > expectation of developers (see, for example, > https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html). > > Thus we propose that `IO` printing and reading are based on `System.out` and > `System.in`, respectively. > > We do not plan to add other functionality to the `IO` class, e.g. a `readInt` > method, in JDK 25. We observe: > > 1. This JEP is not the final word on improving the on-ramp experience in Java, > but merely the first step. We can continue to work on this area in future > JEPs. yes, > > 2. I/O and data conversion are, we believe, separate concerns and, as such, data > conversion doesn't belong in a basic I/O class. Conversion, and in particular > the related issues around error handling, can be considered separately, > and given the auto-import of the `java.base` module, we can easily add > additional utility classes in support of this in future releases. yes > > ## 3. Revise some terminology > > We're going to replace the term "simple compilation unit" with "**compact** > compilation unit" in the spec (and replace "simple source file" with "compact > source file" in the JEP text). Hopefully, "compact" is more concrete, evocative > terminology (and we have used it elsewhere with records). yes, > > > Comments welcome! > > Thanks, > Gavin R?mi From forax at univ-mlv.fr Tue Jan 21 20:48:07 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 21 Jan 2025 21:48:07 +0100 (CET) Subject: Finalising the on-ramp feature In-Reply-To: <0AF97878-A2C7-4189-A146-57D5BC0D6005@oracle.com> References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> <0AF97878-A2C7-4189-A146-57D5BC0D6005@oracle.com> Message-ID: <444088668.72101111.1737492487835.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Gavin Bierman" > To: "amber-spec-experts" > Cc: "amber-dev" > Sent: Tuesday, January 21, 2025 8:06:46 PM > Subject: Re: Finalising the on-ramp feature > [Resending with correction] > > # Finalising the on-ramp feature > > With JDK 24 preparations complete, we are now planning our work for JDK 25 and > in particular the on-ramp JEP. It is our intention to *finalise* the on-ramp > feature in JDK 25. We are grateful for the feedback that we have received from > our expert and developer communities - thank you! - and we have been performing > our own extensive in-house experiments with the preview feature. Given this, we > propose that we make the following changes/simplifications to the feature when > it finalizes in JDK 25. > > ## 1. Remove the auto-static-import feature and move the `IO` class > > We had proposed that the static members of a new class `IO` would automatically > be imported by simple compilation units. This allows the use of the simple names > `println`, `print`, and `readln`. Whilst this is very convenient, it creates a > bump in the on-ramp experience when migrating a simple compilation unit to an > ordinary compilation unit, which does not implicitly import these static > methods. This means that when migrating we either add an explicit static import, > or rewrite all the `println`, `print`, and `readln` method calls to qualified > calls. > > We have come to the conclusion that the graceful on-ramp experience is the more > important goal. So, we propose in JDK 25 that (1) we drop the automatic static > import of the `IO` class by simple compilation units, and (2) We move the `IO` > class from package `java.io` to `java.lang`. > > This means that in simple compilation units calls to the `IO` methods should be > qualified, i.e. `IO.println`, `IO.print`, and `IO.readln`. However, > when migrating from a simple compilation unit to an ordinary compilation unit, > no static import declaration will need to be added, nor will any of these calls > need to be rewritten; the on-ramp experience is simpler. For example: > > ``` > // Simple.java > void main() { > IO.println("Hello, world."); > } > ``` > > is migrated to: > > ``` > // Ordinary.java > class Ordinary { > void main() { > IO.println("Hello, world.?); > } > } > ``` I am a little disapointed by this proposal, As a teacher, it means that you have to explain the dot syntax early on, which is not necessary when discovering basic things like literals, control flow, arrays, user defined functions (yes, functions not methods, because the compact class is not visible, so everything is a function). Yes, later on, when you explain the concept of IO, the dot syntax ('.'), the "println" inside "IO", the "parseInt" inside "Integer". But for the first lectures, there is no need to introduce the dot syntax. More fundamentally, this proposal is weird to me, we want to introduce compact classes so there no need to declare a container class but to print something, you have to us a syntax that says go into the container class "IO" to find the method "println". So compact class => no container class, IO.println => container class ?? I understand that it means that the migration from a compact class to an ordinary class can be seen as more complex, but it's because you are skiping an intermediary step, which is moving from the world of functions to the world of methods. I think that the world of functions is important enough so we should support it, by allowing "println" to be an alias of "IO.println" regards, R?mi From ethan at mccue.dev Wed Jan 22 01:20:52 2025 From: ethan at mccue.dev (Ethan McCue) Date: Tue, 21 Jan 2025 20:20:52 -0500 Subject: Finalising the on-ramp feature In-Reply-To: References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> Message-ID: My phrasing is based on how Brian phrased it > If it's in java.io, then the java.base module import picks up IO for implicit compilation units, but not for named ones, so the locution "IO.println" stops working without an explicit module import, as well as all the existing Java code out there. By putting IO in java.lang, then `IO.x` means the same thing for all compilation units. To be more concrete: both code samples A and B are valid "locutions" A: void main() { var message = "Hello, world"; IO.println(message); } B: void main() { var message = List.of("Hello", "world"); IO.println(message); } But B cannot be evolved into a named class without either an extra import. A, however, can. What I thought was notable was that, in the learning paths that make use of classes like List, you have to have import module java.base; as part of the translation to named class. Where having IO in java.lang helps make that transition in a world where you do not have import module java.base; My imagined reasoning is that it allows for both paths that do and do not cover classes outside of java.lang to coexist. If you stay within what would be available sans the import module java.base; then you don't need to explain it until much later. If you use ArrayList you can at least delay the import module explanation a little later. With that thought I'm satisfied. On Tue, Jan 21, 2025 at 2:32?PM David Alayachew wrote: > How are they different? > > On Tue, Jan 21, 2025, 12:53?PM Ethan McCue wrote: > >> I guess what I'm wrestling with is that, with an implicit import module >> java.base, now List.of means a different thing for implicit compilation >> units than for named ones. >> >> On Tue, Jan 21, 2025 at 12:23?PM Brian Goetz >> wrote: >> >>> Consistency, and smoothing the entry to the highway. >>> >>> If it's in java.io, then the java.base module import picks up IO for >>> implicit compilation units, but not for named ones, so the locution >>> "IO.println" stops working without an explicit module import, as well as >>> all the existing Java code out there. By putting IO in java.lang, then >>> `IO.x` means the same thing for all compilation units. >>> >>> Essentially, it is a combination of uniformity and strength-reduction >>> from "import-static a whole bunch of things in implicit classes only" to >>> "import one new class symbol, IO, everywhere." >>> >>> >>> On 1/21/2025 12:17 PM, Ethan McCue wrote: >>> >>> One question I have: If the implicit import module java.base; remains, >>> what was the impetus for moving IO to java.lang? >>> >>> On Tue, Jan 21, 2025 at 9:55?AM Gavin Bierman >>> wrote: >>> >>>> Dear Experts, >>>> >>>> With JDK 24 preparations complete, we are now planning our work for JDK >>>> 25 and >>>> in particular the on-ramp JEP. It is our intention to *finalise* the >>>> on-ramp >>>> feature in JDK 25. We are grateful for the feedback that we have >>>> received from >>>> our expert and developer communities - thank you! - and we have been >>>> performing >>>> our own extensive in-house experiments with the preview feature. Given >>>> this, we >>>> propose that we make the following changes/simplifications to the >>>> feature when >>>> it finalizes in JDK 25. >>>> >>>> ## 1. Remove the auto-static-import feature and move the `IO` class >>>> >>>> We had proposed that the static members of a new class `IO` would >>>> automatically >>>> be imported by simple compilation units. This allows the use of the >>>> simple names >>>> `println`, `print`, `readln`, and `read`. Whilst this is very >>>> convenient, it >>>> creates a bump in the on-ramp experience when migrating a simple >>>> compilation >>>> unit to an ordinary compilation unit, which does not implicitly import >>>> these static >>>> methods. This means that when migrating we either add an explicit >>>> static import, >>>> or rewrite all the `println`, `print`, `readln` and `read` method calls >>>> to >>>> qualified calls. >>>> >>>> We have come to the conclusion that the graceful on-ramp experience is >>>> the more >>>> important goal. So, we propose in JDK 25 that (1) we drop the automatic >>>> static >>>> import of the `IO` class by simple compilation units, and (2) We move >>>> the `IO` >>>> class from package `java.io` to `java.lang`. >>>> >>>> This means that in simple compilation units calls to the `IO` methods >>>> should be >>>> qualified, i.e. `IO.println`, `IO.print`, `IO.readln` and `IO.read`. >>>> However, >>>> when migrating from a simple compilation unit to an ordinary >>>> compilation unit, >>>> no static import declaration will need to be added, nor will any of >>>> these calls >>>> need to be rewritten; the on-ramp experience is simpler. For example: >>>> >>>> ``` >>>> // Simple.java >>>> void main() { >>>> IO.println("Hello, world."); >>>> } >>>> ``` >>>> >>>> is migrated to: >>>> >>>> ``` >>>> // Ordinary.java >>>> class Ordinary { >>>> void main() { >>>> IO.println("Hello, world.?); >>>> } >>>> } >>>> ``` >>>> >>>> >>>> ## 2. Changes to the `IO` class >>>> >>>> The new `IO` class is intended to contain the most basic line-oriented >>>> I/O >>>> methods for beginners. >>>> >>>> Currently the implementation of the methods of this class are thin >>>> wrappers >>>> around their equivalents in the `Console` class. We propose in JDK 25 to >>>> decouple `IO` completely from `Console` which we think will better >>>> reflect the >>>> expectation of developers (see, for example, >>>> https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html >>>> ). >>>> >>>> Thus we propose that `IO` printing and reading are based on >>>> `System.out` and >>>> `System.in`, respectively. >>>> >>>> We do not plan to add other functionality to the `IO` class, e.g. a >>>> `readInt` >>>> method, in JDK 25. We observe: >>>> >>>> 1. This JEP is not the final word on improving the on-ramp experience >>>> in Java, >>>> but merely the first step. We can continue to work on this area in >>>> future >>>> JEPs. >>>> >>>> 2. I/O and data conversion are, we believe, separate concerns and, as >>>> such, data >>>> conversion doesn't belong in a basic I/O class. Conversion, and in >>>> particular >>>> the related issues around error handling, can be considered separately, >>>> and given the auto-import of the `java.base` module, we can easily add >>>> additional utility classes in support of this in future releases. >>>> >>>> ## 3. Revise some terminology >>>> >>>> We're going to replace the term "simple compilation unit" with >>>> "**compact** >>>> compilation unit" in the spec (and replace "simple source file" with >>>> "compact >>>> source file" in the JEP text). Hopefully, "compact" is more concrete, >>>> evocative >>>> terminology (and we have used it elsewhere with records). >>>> >>>> >>>> Comments welcome! >>>> >>>> Thanks, >>>> Gavin >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Wed Jan 22 01:32:06 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Tue, 21 Jan 2025 20:32:06 -0500 Subject: Finalising the on-ramp feature In-Reply-To: References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> Message-ID: Hmmmm. I see doing the module import as a small enough lift. Same as the amount of lift needed to add void main(). For me, the big goal of this jep is to remove the major road stops on the on-ramp. Forcing people to add a module import seems small enough to be acceptable. On Tue, Jan 21, 2025, 8:21?PM Ethan McCue wrote: > My phrasing is based on how Brian phrased it > > > If it's in java.io, then the java.base module import picks up IO for > implicit compilation units, but not for named ones, so the locution > "IO.println" stops working without an explicit module import, as well as > all the existing Java code out there. By putting IO in java.lang, then > `IO.x` means the same thing for all compilation units. > > To be more concrete: both code samples A and B are valid "locutions" > > A: > void main() { > var message = "Hello, world"; > IO.println(message); > } > > B: > void main() { > var message = List.of("Hello", "world"); > IO.println(message); > } > > But B cannot be evolved into a named class without either an extra import. > A, however, can. > > What I thought was notable was that, in the learning paths that make use > of classes like List, you have to have import module java.base; as part > of the translation to named class. Where having IO in java.lang helps > make that transition in a world where you do not have import module > java.base; > > My imagined reasoning is that it allows for both paths that do and do not > cover classes outside of java.lang to coexist. If you stay within what > would be available sans the import module java.base; then you don't need > to explain it until much later. If you use ArrayList you can at least > delay the import module explanation a little later. With that thought I'm > satisfied. > > On Tue, Jan 21, 2025 at 2:32?PM David Alayachew > wrote: > >> How are they different? >> >> On Tue, Jan 21, 2025, 12:53?PM Ethan McCue wrote: >> >>> I guess what I'm wrestling with is that, with an implicit import module >>> java.base, now List.of means a different thing for implicit compilation >>> units than for named ones. >>> >>> On Tue, Jan 21, 2025 at 12:23?PM Brian Goetz >>> wrote: >>> >>>> Consistency, and smoothing the entry to the highway. >>>> >>>> If it's in java.io, then the java.base module import picks up IO for >>>> implicit compilation units, but not for named ones, so the locution >>>> "IO.println" stops working without an explicit module import, as well as >>>> all the existing Java code out there. By putting IO in java.lang, then >>>> `IO.x` means the same thing for all compilation units. >>>> >>>> Essentially, it is a combination of uniformity and strength-reduction >>>> from "import-static a whole bunch of things in implicit classes only" to >>>> "import one new class symbol, IO, everywhere." >>>> >>>> >>>> On 1/21/2025 12:17 PM, Ethan McCue wrote: >>>> >>>> One question I have: If the implicit import module java.base; remains, >>>> what was the impetus for moving IO to java.lang? >>>> >>>> On Tue, Jan 21, 2025 at 9:55?AM Gavin Bierman >>>> wrote: >>>> >>>>> Dear Experts, >>>>> >>>>> With JDK 24 preparations complete, we are now planning our work for >>>>> JDK 25 and >>>>> in particular the on-ramp JEP. It is our intention to *finalise* the >>>>> on-ramp >>>>> feature in JDK 25. We are grateful for the feedback that we have >>>>> received from >>>>> our expert and developer communities - thank you! - and we have been >>>>> performing >>>>> our own extensive in-house experiments with the preview feature. Given >>>>> this, we >>>>> propose that we make the following changes/simplifications to the >>>>> feature when >>>>> it finalizes in JDK 25. >>>>> >>>>> ## 1. Remove the auto-static-import feature and move the `IO` class >>>>> >>>>> We had proposed that the static members of a new class `IO` would >>>>> automatically >>>>> be imported by simple compilation units. This allows the use of the >>>>> simple names >>>>> `println`, `print`, `readln`, and `read`. Whilst this is very >>>>> convenient, it >>>>> creates a bump in the on-ramp experience when migrating a simple >>>>> compilation >>>>> unit to an ordinary compilation unit, which does not implicitly import >>>>> these static >>>>> methods. This means that when migrating we either add an explicit >>>>> static import, >>>>> or rewrite all the `println`, `print`, `readln` and `read` method >>>>> calls to >>>>> qualified calls. >>>>> >>>>> We have come to the conclusion that the graceful on-ramp experience is >>>>> the more >>>>> important goal. So, we propose in JDK 25 that (1) we drop the >>>>> automatic static >>>>> import of the `IO` class by simple compilation units, and (2) We move >>>>> the `IO` >>>>> class from package `java.io` to `java.lang`. >>>>> >>>>> This means that in simple compilation units calls to the `IO` methods >>>>> should be >>>>> qualified, i.e. `IO.println`, `IO.print`, `IO.readln` and `IO.read`. >>>>> However, >>>>> when migrating from a simple compilation unit to an ordinary >>>>> compilation unit, >>>>> no static import declaration will need to be added, nor will any of >>>>> these calls >>>>> need to be rewritten; the on-ramp experience is simpler. For example: >>>>> >>>>> ``` >>>>> // Simple.java >>>>> void main() { >>>>> IO.println("Hello, world."); >>>>> } >>>>> ``` >>>>> >>>>> is migrated to: >>>>> >>>>> ``` >>>>> // Ordinary.java >>>>> class Ordinary { >>>>> void main() { >>>>> IO.println("Hello, world.?); >>>>> } >>>>> } >>>>> ``` >>>>> >>>>> >>>>> ## 2. Changes to the `IO` class >>>>> >>>>> The new `IO` class is intended to contain the most basic line-oriented >>>>> I/O >>>>> methods for beginners. >>>>> >>>>> Currently the implementation of the methods of this class are thin >>>>> wrappers >>>>> around their equivalents in the `Console` class. We propose in JDK 25 >>>>> to >>>>> decouple `IO` completely from `Console` which we think will better >>>>> reflect the >>>>> expectation of developers (see, for example, >>>>> https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html >>>>> ). >>>>> >>>>> Thus we propose that `IO` printing and reading are based on >>>>> `System.out` and >>>>> `System.in`, respectively. >>>>> >>>>> We do not plan to add other functionality to the `IO` class, e.g. a >>>>> `readInt` >>>>> method, in JDK 25. We observe: >>>>> >>>>> 1. This JEP is not the final word on improving the on-ramp experience >>>>> in Java, >>>>> but merely the first step. We can continue to work on this area in >>>>> future >>>>> JEPs. >>>>> >>>>> 2. I/O and data conversion are, we believe, separate concerns and, as >>>>> such, data >>>>> conversion doesn't belong in a basic I/O class. Conversion, and in >>>>> particular >>>>> the related issues around error handling, can be considered separately, >>>>> and given the auto-import of the `java.base` module, we can easily add >>>>> additional utility classes in support of this in future releases. >>>>> >>>>> ## 3. Revise some terminology >>>>> >>>>> We're going to replace the term "simple compilation unit" with >>>>> "**compact** >>>>> compilation unit" in the spec (and replace "simple source file" with >>>>> "compact >>>>> source file" in the JEP text). Hopefully, "compact" is more concrete, >>>>> evocative >>>>> terminology (and we have used it elsewhere with records). >>>>> >>>>> >>>>> Comments welcome! >>>>> >>>>> Thanks, >>>>> Gavin >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cay.horstmann at gmail.com Wed Jan 22 07:24:29 2025 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Wed, 22 Jan 2025 08:24:29 +0100 Subject: Finalising the on-ramp feature In-Reply-To: <444088668.72101111.1737492487835.JavaMail.zimbra@univ-eiffel.fr> References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> <0AF97878-A2C7-4189-A146-57D5BC0D6005@oracle.com> <444088668.72101111.1737492487835.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Il 21/01/2025 21:48, Remi Forax ha scritto: > I am a little disapointed by this proposal, > As a teacher, it means that you have to explain the dot syntax early on, which is not necessary when discovering basic things like literals, control flow, arrays, user defined functions (yes, functions not methods, because the compact class is not visible, so everything is a function). > > Yes, later on, when you explain the concept of IO, the dot syntax ('.'), the "println" inside "IO", the "parseInt" inside "Integer". > But for the first lectures, there is no need to introduce the dot syntax. > > More fundamentally, this proposal is weird to me, we want to introduce compact classes so there no need to declare a container class but to print something, you have to us a syntax that says go into the container class "IO" to find the method "println". So compact class => no container class, IO.println => container class ?? > > I understand that it means that the migration from a compact class to an ordinary class can be seen as more complex, but it's because you are skiping an intermediary step, which is moving from the world of functions to the world of methods. I think that the world of functions is important enough so we should support it, by allowing "println" to be an alias of "IO.println" > It would be difficult to avoid Integer.parseInt, Math.pow, and so on in a Java-based introduction to programming. But why the fear of the dot? It marks these as coming from elsewhere. Good for the beginner to know. A clean and consistent model. No dot: defined in the compact class. With dot: defined in the API. That's why I favor IO.println over unqualified println. It's consistent. It would also be consistent if one could use unqualified parseInt, pow, println, etc., but nobody has come up with a satisfactory on-ramp, and not for lack of trying. Cheers, Cay -- Cay S. Horstmann | https://horstmann.com From kfogel at dawsoncollege.qc.ca Wed Jan 22 16:44:09 2025 From: kfogel at dawsoncollege.qc.ca (Kenneth Fogel) Date: Wed, 22 Jan 2025 16:44:09 +0000 Subject: Finalising the on-ramp feature In-Reply-To: References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> <0AF97878-A2C7-4189-A146-57D5BC0D6005@oracle.com> <444088668.72101111.1737492487835.JavaMail.zimbra@univ-eiffel.fr> Message-ID: I'm puzzled. Will I need any imports if what I want comes from java.base in the compact format? The statement that now requiring "IO." before the input/output statements will make the transition from compact to api easier is, for me, false. It is just one more item in those first classes where we must tell our students not to worry themselves over the dot notation. It will eventually make sense. I'd like to see a poll of instructors asking which methods should have a default static import. As already mentioned, I'd like to see pow rather than Math.pow. I'd take it even further and suggest that the entire Math library should have default static imports. Make it a feature you can turn on or off when using java.exe to compile and execute. No need to tell me why this won't work in an API world, I can see why, but it will work in a compact world. This is a world exclusively for teaching the language. No one is likely to develop an application for distribution using compact syntax. It is a stepping stone. Ken From forax at univ-mlv.fr Wed Jan 22 17:22:14 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 22 Jan 2025 18:22:14 +0100 (CET) Subject: Finalising the on-ramp feature In-Reply-To: References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> <0AF97878-A2C7-4189-A146-57D5BC0D6005@oracle.com> <444088668.72101111.1737492487835.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1754553388.73571449.1737566534322.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "cay horstmann" > To: "amber-dev" > Sent: Wednesday, January 22, 2025 8:24:29 AM > Subject: Re: Finalising the on-ramp feature > Il 21/01/2025 21:48, Remi Forax ha scritto: >> I am a little disapointed by this proposal, >> As a teacher, it means that you have to explain the dot syntax early on, which >> is not necessary when discovering basic things like literals, control flow, >> arrays, user defined functions (yes, functions not methods, because the compact >> class is not visible, so everything is a function). >> >> Yes, later on, when you explain the concept of IO, the dot syntax ('.'), the >> "println" inside "IO", the "parseInt" inside "Integer". >> But for the first lectures, there is no need to introduce the dot syntax. >> >> More fundamentally, this proposal is weird to me, we want to introduce compact >> classes so there no need to declare a container class but to print something, >> you have to us a syntax that says go into the container class "IO" to find the >> method "println". So compact class => no container class, IO.println => >> container class ?? >> >> I understand that it means that the migration from a compact class to an >> ordinary class can be seen as more complex, but it's because you are skiping an >> intermediary step, which is moving from the world of functions to the world of >> methods. I think that the world of functions is important enough so we should >> support it, by allowing "println" to be an alias of "IO.println" >> > > It would be difficult to avoid Integer.parseInt, Math.pow, and so on in a > Java-based introduction to programming. But why the fear of the dot? It marks > these as coming from elsewhere. Good for the beginner to know. A clean and > consistent model. No dot: defined in the compact class. With dot: defined in > the API. > > That's why I favor IO.println over unqualified println. It's consistent. > > It would also be consistent if one could use unqualified parseInt, pow, println, > etc., but nobody has come up with a satisfactory on-ramp, and not for lack of > trying. For me it depends on the skills of the students, if students have aready seen Python or C, yes, there is no point to use println instead of IO.println(), I would even say quite the oposite, you want to explain what an object is sooner than later, but if Java is used as first langage, there is no need to do IOs in the beginning, because you need to teach both very basic data structures and very basic algorithms. At my UNI, we teach to not mixed computation and IO very early on, so print is enough, and Integer.parseInt() does not exist. But perhaps, our cursus or more functional that in other UNIs ? > > Cheers, > > Cay > > -- > > Cay S. Horstmann | https://horstmann.com regards, R?mi From ethan at mccue.dev Wed Jan 22 17:48:47 2025 From: ethan at mccue.dev (Ethan McCue) Date: Wed, 22 Jan 2025 12:48:47 -0500 Subject: Finalising the on-ramp feature In-Reply-To: References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> <0AF97878-A2C7-4189-A146-57D5BC0D6005@oracle.com> <444088668.72101111.1737492487835.JavaMail.zimbra@univ-eiffel.fr> Message-ID: You will need an import when you make the transition from an unnamed to a named class if you have anything coming from java.base that is not also in java.lang. The difference is that now the only import you need is import module java.base;, not also import static java.io.IO.*; On Wed, Jan 22, 2025 at 12:27?PM Kenneth Fogel wrote: > I'm puzzled. Will I need any imports if what I want comes from java.base > in the compact format? > > The statement that now requiring "IO." before the input/output statements > will make the transition from compact to api easier is, for me, false. It > is just one more item in those first classes where we must tell our > students not to worry themselves over the dot notation. It will eventually > make sense. > > I'd like to see a poll of instructors asking which methods should have a > default static import. As already mentioned, I'd like to see pow rather > than Math.pow. I'd take it even further and suggest that the entire Math > library should have default static imports. Make it a feature you can turn > on or off when using java.exe to compile and execute. No need to tell me > why this won't work in an API world, I can see why, but it will work in a > compact world. This is a world exclusively for teaching the language. No > one is likely to develop an application for distribution using compact > syntax. It is a stepping stone. > > Ken > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scolebourne at joda.org Tue Jan 28 16:33:23 2025 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 28 Jan 2025 16:33:23 +0000 Subject: Finalising the on-ramp feature In-Reply-To: References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com> <0AF97878-A2C7-4189-A146-57D5BC0D6005@oracle.com> <444088668.72101111.1737492487835.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On Wed, 22 Jan 2025 at 07:25, Cay Horstmann wrote: > It would be difficult to avoid Integer.parseInt, Math.pow, and so on in a Java-based introduction to programming. But why the fear of the dot? It marks these as coming from elsewhere. Good for the beginner to know. A clean and consistent model. No dot: defined in the compact class. With dot: defined in the API. I just wanted to add that this is a great way to look at it. Requiring the "IO." will make IO consistent with "Math." or "Double." which beginners will no doubt use before progressing to normal classes. >From my perspective, the JEP is fine now (not the language change I would have made, but a perfectly fine alternative). Stephen From amaembo at gmail.com Fri Jan 31 12:49:31 2025 From: amaembo at gmail.com (Tagir Valeev) Date: Fri, 31 Jan 2025 13:49:31 +0100 Subject: Running static main method inside abstract class, containing another main method Message-ID: Hello! The following message related to JEP 495 "Simple Source Files and Instance Main Methods" was posted by my colleague, Mikhail Pyltsin, to compiler-dev, but probably it belongs better to amber-dev. Mikhail told me that he has trouble posting to amber-dev. According to him, messages go to the moderation queue and never appear on the list. Now, I'm reposting his message under my name, as the problem looks somewhat important to me. The original message follows. Hi! Sorry, I am not sure that it is a correct channel, but probably, it is related to jep specification. I am investigating a new version of jep495 ( https://cr.openjdk.org/~gbierman/jep495/jep495-20241101/specs/simple-source-files-instance-main-methods-jls.html#jls-12.1.3 ) and came up with such an example: ```java public abstract class AbstractClass { public static void main() { System.out.println("Hello, World!"); } public void main(String[] args) { System.out.println("Hello, World! no constructor, non-static, args"); } } ``` Right now java chooses `void main(String[] args) ` because it contains argument, but cannot create this class, because it is abstract, I have got this error: `Exception in thread "main" java.lang.InstantiationException: AbstractClass` Could you help me if this is expected? I expect that `public static void main()` will be chosen. I cannot find anything related to this in JEP except this one: `The behavior of an implementation if there is no candidate method to invoke, or if there is no suitable constructor in the initial class when invoking an instance candidate method, is beyond the scope of this specification.', but it doesn't contain this case. With best regards, Tagir Valeev -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at yawk.at Fri Jan 31 13:35:41 2025 From: me at yawk.at (Jonas Konrad) Date: Fri, 31 Jan 2025 14:35:41 +0100 Subject: Running static main method inside abstract class, containing another main method In-Reply-To: References: Message-ID: <4c1e148f-2e42-47e0-9710-300ead663df2@yawk.at> Hi, This seems in line with the spec to me. The rules are: - If there is a candidate method with a single formal parameter then this method is invoked. [...] - Otherwise, if there is a candidate method with no formal parameters then this method is invoked. [...] `public void main(String[] args)` is a valid candidate method, so the first rule applies, and the second one does not. There is nothing that says that the second rule acts as fallback if the first invocation fails for whatever reason. - Jonas On 1/31/25 1:49 PM, Tagir Valeev wrote: > Hello! > > The following message related to JEP 495 "Simple Source Files and > Instance Main Methods" was posted by my colleague, Mikhail Pyltsin, to > compiler-dev, but probably it belongs better to amber-dev. Mikhail told > me that he has trouble posting to amber-dev. According to him, messages > go to the moderation queue and never appear on the list. Now, I'm > reposting his message under my name, as the problem looks somewhat > important to me. The original message follows. > > Hi! > Sorry, I am not sure that it is a correct channel, but probably, it is > related to jep specification. > I am investigating a new version of ?jep495 > ( > https://cr.openjdk.org/~gbierman/jep495/jep495-20241101/specs/simple- > source-files-instance-main-methods-jls.html#jls-12.1.3 cr.openjdk.org/~gbierman/jep495/jep495-20241101/specs/simple-source- > files-instance-main-methods-jls.html#jls-12.1.3> > ) > and came up with such an example: > ```java > public abstract class AbstractClass { > ? ? public static void main() { > ? ? ? ? System.out.println("Hello, World!"); > ? ? } > > ? ? public void main(String[] args) { > ? ? ? ? System.out.println("Hello, World! no constructor, non-static, > args"); > ? ? } > } > ``` > Right now java chooses `void main(String[] args) ` because it contains > argument, but cannot create this class, because it is abstract, > I have got this error: `Exception in thread "main" > java.lang.InstantiationException: AbstractClass` > Could you help me if this is expected? I expect that `public static void > main()` will be chosen. > > I cannot find anything related to this in JEP except this one: > `The behavior of an implementation if there is no candidate method to > invoke, or if there is no suitable constructor in the initial class when > invoking an instance candidate method, is beyond the scope of this > specification.', but it doesn't contain this case. > > > With best regards, > Tagir Valeev