Finalising the on-ramp feature

[Ethan McCue]

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` 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-dev/attachments/20250121/18815e89/attachment.htm>