Finalising the on-ramp feature

[Remi Forax]

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