Finalising the on-ramp feature

Cay Horstmann cay.horstmann at gmail.com
Tue Jan 21 18:55:26 UTC 2025


+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



More information about the amber-spec-observers mailing list