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