----- Original Message ----- > From: "Gavin Bierman" <[email protected]> > To: "amber-spec-experts" <[email protected]> > Cc: "amber-dev" <[email protected]> > 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
