Consistency, and smoothing the entry to the highway.
If it's in java.io, then the java.base module import picks up IO for
implicit compilation units, but not for named ones, so the locution
"IO.println" stops working without an explicit module import, as well as
all the existing Java code out there. By putting IO in java.lang, then
`IO.x` means the same thing for all compilation units.
Essentially, it is a combination of uniformity and strength-reduction
from "import-static a whole bunch of things in implicit classes only" to
"import one new class symbol, IO, everywhere."
On 1/21/2025 12:17 PM, Ethan McCue wrote:
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
<[email protected]> 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 <http://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
