<div dir="auto"><div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jan 21, 2025, 2:49 PM Remi Forax <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
----- Original Message -----<br>
> From: "Gavin Bierman" <<a href="mailto:gavin.bierman@oracle.com" target="_blank" rel="noreferrer">gavin.bierman@oracle.com</a>><br>
> To: "amber-spec-experts" <<a href="mailto:amber-spec-experts@openjdk.java.net" target="_blank" rel="noreferrer">amber-spec-experts@openjdk.java.net</a>><br>
> Cc: "amber-dev" <<a href="mailto:amber-dev@openjdk.org" target="_blank" rel="noreferrer">amber-dev@openjdk.org</a>><br>
> Sent: Tuesday, January 21, 2025 8:06:46 PM<br>
> Subject: Re: Finalising the on-ramp feature<br>
<br>
> [Resending with correction]<br>
> <br>
> # Finalising the on-ramp feature<br>
> <br>
> With JDK 24 preparations complete, we are now planning our work for JDK 25 and<br>
> in particular the on-ramp JEP. It is our intention to *finalise* the on-ramp<br>
> feature in JDK 25. We are grateful for the feedback that we have received from<br>
> our expert and developer communities - thank you! - and we have been performing<br>
> our own extensive in-house experiments with the preview feature. Given this, we<br>
> propose that we make the following changes/simplifications to the feature when<br>
> it finalizes in JDK 25.<br>
> <br>
> ## 1. Remove the auto-static-import feature and move the `IO` class<br>
> <br>
> We had proposed that the static members of a new class `IO` would automatically<br>
> be imported by simple compilation units. This allows the use of the simple names<br>
> `println`, `print`, and `readln`. Whilst this is very convenient, it creates a<br>
> bump in the on-ramp experience when migrating a simple compilation unit to an<br>
> ordinary compilation unit, which does not implicitly import these static<br>
> methods. This means that when migrating we either add an explicit static import,<br>
> or rewrite all the `println`, `print`, and `readln` method calls to qualified<br>
> calls.<br>
> <br>
> We have come to the conclusion that the graceful on-ramp experience is the more<br>
> important goal. So, we propose in JDK 25 that (1) we drop the automatic static<br>
> import of the `IO` class by simple compilation units, and (2) We move the `IO`<br>
> class from package `<a href="http://java.io" rel="noreferrer noreferrer" target="_blank">java.io</a>` to `java.lang`.<br>
> <br>
> This means that in simple compilation units calls to the `IO` methods should be<br>
> qualified, i.e. `IO.println`, `IO.print`, and `IO.readln`. However,<br>
> when migrating from a simple compilation unit to an ordinary compilation unit,<br>
> no static import declaration will need to be added, nor will any of these calls<br>
> need to be rewritten; the on-ramp experience is simpler. For example:<br>
> <br>
> ```<br>
> // Simple.java<br>
> void main() {<br>
>    IO.println("Hello, world.");<br>
> }<br>
> ```<br>
> <br>
> is migrated to:<br>
> <br>
> ```<br>
> // Ordinary.java<br>
> class Ordinary {<br>
>    void main() {<br>
>        IO.println("Hello, world.”);<br>
>    }<br>
> }<br>
> ```<br>
<br>
I am a little disapointed by this proposal,<br>
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).<br>
<br>
Yes, later on, when you explain the concept of IO, the dot syntax ('.'), the "println" inside "IO", the "parseInt" inside "Integer".<br>
But for the first lectures, there is no need to introduce the dot syntax.<br>
<br>
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 ??<br>
<br>
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"<br>
<br>
regards,<br>
Rémi<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I agree. The goal is to make it extremely simple for beginners to write basic Java programs. Writing HelloWorld.java should be as easy as writing hello-world.sh or <a href="http://hello-world.pl">hello-world.pl</a>. I think an implicit `import static java.lang.IO.*;` is reasonable to provide a smoother ramp. There's a simple migration path once dot notation is intoduced from `println()` to `IO.println`, without forcing it up front.</div><div dir="auto"><br></div><div dir="auto">If we're going to require beginners to learn dot notation right out of the gate, it would be simpler to statically import System.in and System.out in compact source files and dispense with the IO class entirely.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Clement Cherlin</div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div></div>