Finalising the on-ramp feature
Clement Cherlin
ccherlin at gmail.com
Fri Jan 24 15:09:14 UTC 2025
On Fri, Jan 24, 2025, 8:57 AM Clement Cherlin <ccherlin at gmail.com> wrote:
> On Tue, Jan 21, 2025, 2:49 PM Remi Forax <forax at univ-mlv.fr> wrote:
>
>>
>>
>> ----- Original Message -----
>> > From: "Gavin Bierman" <gavin.bierman at oracle.com>
>> > To: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>> > Cc: "amber-dev" <amber-dev at openjdk.org>
>> > 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
>>
>
> 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 hello-world.pl. 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.
>
> 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.
>
> Cheers,
> Clement Cherlin
>
Correction: `out` would be adequate for output. For input a BufferedReader
wrapper around `in` would still be required.
Cheers,
Clement Cherlin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20250124/593a5175/attachment.htm>
More information about the amber-spec-observers
mailing list