From ccherlin at gmail.com  Thu Jan  9 19:57:30 2025
From: ccherlin at gmail.com (Clement Cherlin)
Date: Thu, 9 Jan 2025 13:57:30 -0600
Subject: JDK-8300691 - final variables in for loop headers should accept
 updates
In-Reply-To: <CANSoFxvowYVCXgUFsXvi+ikmQF8-sHH5sjr+HtSe5rRnmXrfqQ@mail.gmail.com>
References: <CANSoFxujHjvosGziHof+-7cO6TuJ-UZP7dtucuG0Edbrem93iQ@mail.gmail.com>
 <CANSoFxvowYVCXgUFsXvi+ikmQF8-sHH5sjr+HtSe5rRnmXrfqQ@mail.gmail.com>
Message-ID: <CALEU8=zDswuAF26Y_VodNbjssCpNY+XD6GJeGy7dv-RMJ3DAhw@mail.gmail.com>

On Thu, Dec 19, 2024 at 9:19?AM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Wed, Dec 11, 2024 at 2:25?PM Archie Cobbs <archie.cobbs at gmail.com>
> wrote:
>
>> There is a (small) language change under consideration on amber-dev, and
>> opinions have been expressed in multiple directions, so I'm turning to this
>> list for hopefully some authoritative adjudication.
>>
>
> Since I didn't hear an overwhelming roar of approval, I'll shelve this for
> now. The issues and PR will still be there if/when we want to take this up
> again in the future.
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>

I know I'm late on this, but I think the right way to address deficiencies
like this in old-style for loops is to make enhanced for loops better in
ways that reduce/eliminate the need for old-style for loops. That approach
has been very successful with enhanced switch.

A simple and efficient way to use a simple range or arithmetic progression
in enhanced for loops could replace 99% of uses of old-style for loops.

Since there's no such thing as PrimitiveIterable, I presume that will
require primitive specialization (JEP 218) from Valhalla. Primitive
specialization will make it possible to use Iterable<int> instead of
Iterable<Integer>.

A second, orthogonal improvement would be ImmutableIterator and
ImmutableIterable interfaces that the enhanced for loop understands, making
it possible to write value-based iterators.

In addition to being able to lambda-capture the loop variable, "for (final
int i : Range.closed(0, 9)) {...}" is much easier to read (and less
vulnerable to off-by-one errors) than the old-style for loop "for (int i =
0; i <= 9; ++i) {...}"

Cheers,
Clement
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20250109/00702c7a/attachment-0001.htm>

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 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: <CA+NR86gdTEGTjyPTbTtraAbEyv18C3sRWvARWSoCv6Dvxf2JcA@mail.gmail.com>
References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com>
 <CA+NR86gdTEGTjyPTbTtraAbEyv18C3sRWvARWSoCv6Dvxf2JcA@mail.gmail.com>
Message-ID: <f005ea4f-139d-4860-b1f8-d7f786088001@oracle.com>

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 
> <gavin.bierman at oracle.com> 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 <http://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: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20250121/8145cd03/attachment-0001.htm>

From cay.horstmann at gmail.com  Tue Jan 21 18:55:26 2025
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Tue, 21 Jan 2025 19:55:26 +0100
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: <9f592295-2de8-471d-82f9-6cb3e1e33026@gmail.com>

+1

But what is IO.read?

Il 21/01/2025 14:28, Gavin Bierman ha scritto:
> 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

-- 

Cay S. Horstmann | https://horstmann.com


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: <D46BF4FA-02EC-40B4-926B-39A2F64BEAF5@oracle.com>


> On 21 Jan 2025, at 18:55, Cay Horstmann <cay.horstmann at gmail.com> wrote:
> 
> +1
> 
> But what is IO.read?

A typo! Thanks Cay - resent with correction.

Many Thanks,
Gavin

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" <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.
> 

[...]


> 
> ## 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" <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

From ccherlin at gmail.com  Fri Jan 24 14:57:07 2025
From: ccherlin at gmail.com (Clement Cherlin)
Date: Fri, 24 Jan 2025 08:57:07 -0600
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: <CALEU8=z1dgky+ARRfURxQMf3thnzTcR_CYR3tQjPG1p=pmKdfA@mail.gmail.com>

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

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20250124/4aa473f7/attachment-0001.htm>

From ccherlin at gmail.com  Fri Jan 24 15:09:14 2025
From: ccherlin at gmail.com (Clement Cherlin)
Date: Fri, 24 Jan 2025 09:09:14 -0600
Subject: Finalising the on-ramp feature
In-Reply-To: <CALEU8=z1dgky+ARRfURxQMf3thnzTcR_CYR3tQjPG1p=pmKdfA@mail.gmail.com>
References: <9C5CBE70-DC9B-4A4D-85CA-7C4A94EA84FE@oracle.com>
 <0AF97878-A2C7-4189-A146-57D5BC0D6005@oracle.com>
 <444088668.72101111.1737492487835.JavaMail.zimbra@univ-eiffel.fr>
 <CALEU8=z1dgky+ARRfURxQMf3thnzTcR_CYR3tQjPG1p=pmKdfA@mail.gmail.com>
Message-ID: <CALEU8=yJNdRe1RaLw73KmFwtAsTuGaqxqfGNLuQ+Z3HwOw8y8g@mail.gmail.com>

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>