Finalising the on-ramp feature

[Ethan McCue]

I guess what I'm wrestling with is that, with an implicit import module
java.base, now List.of means a different thing for implicit compilation
units than for named ones.

On Tue, Jan 21, 2025 at 12:23 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> 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 <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/8ca5ea71/attachment.htm>