<div dir="ltr">One question I have: If the implicit <font face="monospace">import module java.base;</font><font face="arial, sans-serif"> remains, what was the impetus for moving </font><font face="monospace">IO </font><font face="arial, sans-serif">to </font><font face="monospace">java.lang</font><font face="arial, sans-serif">?</font><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jan 21, 2025 at 9:55 AM Gavin Bierman <<a href="mailto:gavin.bierman@oracle.com">gavin.bierman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Experts,<br>
<br>
With JDK 24 preparations complete, we are now planning our work for JDK 25 and<br>
in particular the on-ramp JEP. It is our intention to *finalise* the on-ramp<br>
feature in JDK 25. We are grateful for the feedback that we have received from<br>
our expert and developer communities - thank you! - and we have been performing<br>
our own extensive in-house experiments with the preview feature. Given this, we<br>
propose that we make the following changes/simplifications to the feature when<br>
it finalizes in JDK 25. <br>
<br>
## 1. Remove the auto-static-import feature and move the `IO` class<br>
<br>
We had proposed that the static members of a new class `IO` would automatically<br>
be imported by simple compilation units. This allows the use of the simple names<br>
`println`, `print`, `readln`, and `read`. Whilst this is very convenient, it<br>
creates a bump in the on-ramp experience when migrating a simple compilation<br>
unit to an ordinary compilation unit, which does not implicitly import these static<br>
methods. This means that when migrating we either add an explicit static import,<br>
or rewrite all the `println`, `print`, `readln` and `read` method calls to<br>
qualified calls. <br>
<br>
We have come to the conclusion that the graceful on-ramp experience is the more<br>
important goal. So, we propose in JDK 25 that (1) we drop the automatic static<br>
import of the `IO` class by simple compilation units, and (2) We move the `IO`<br>
class from package `<a href="http://java.io" rel="noreferrer" target="_blank">java.io</a>` to `java.lang`. <br>
<br>
This means that in simple compilation units calls to the `IO` methods should be<br>
qualified, i.e. `IO.println`, `IO.print`, `IO.readln` and `IO.read`. However,<br>
when migrating from a simple compilation unit to an ordinary compilation unit,<br>
no static import declaration will need to be added, nor will any of these calls<br>
need to be rewritten; the on-ramp experience is simpler. For example:<br>
<br>
```<br>
// Simple.java<br>
void main() {<br>
    IO.println("Hello, world.");<br>
}<br>
```<br>
<br>
is migrated to:<br>
<br>
```<br>
// Ordinary.java<br>
class Ordinary {<br>
    void main() {<br>
        IO.println("Hello, world.”);<br>
    }<br>
}<br>
```<br>
<br>
<br>
## 2. Changes to the `IO` class<br>
<br>
The new `IO` class is intended to contain the most basic line-oriented I/O<br>
methods for beginners. <br>
<br>
Currently the implementation of the methods of this class are thin wrappers<br>
around their equivalents in the `Console` class. We propose in JDK 25 to<br>
decouple `IO` completely from `Console` which we think will better reflect the<br>
expectation of developers (see, for example,<br>
<a href="https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html" rel="noreferrer" target="_blank">https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html</a>).<br>
<br>
Thus we propose that `IO` printing and reading are based on `System.out` and<br>
`System.in`, respectively. <br>
<br>
We do not plan to add other functionality to the `IO` class, e.g. a `readInt`<br>
method, in JDK 25. We observe:<br>
<br>
1. This JEP is not the final word on improving the on-ramp experience in Java,<br>
but merely the first step. We can continue to work on this area in future<br>
JEPs.<br>
<br>
2. I/O and data conversion are, we believe, separate concerns and, as such, data<br>
conversion doesn't belong in a basic I/O class. Conversion, and in particular<br>
the related issues around error handling, can be considered separately,<br>
and given the auto-import of the `java.base` module, we can easily add<br>
additional utility classes in support of this in future releases.<br>
<br>
## 3. Revise some terminology<br>
<br>
We're going to replace the term "simple compilation unit" with "**compact**<br>
compilation unit" in the spec (and replace "simple source file" with "compact<br>
source file" in the JEP text). Hopefully, "compact" is more concrete, evocative<br>
terminology (and we have used it elsewhere with records).<br>
<br>
<br>
Comments welcome!<br>
<br>
Thanks,<br>
Gavin </blockquote></div>