Finalising the on-ramp feature

[David Alayachew]

How are they different?

On Tue, Jan 21, 2025, 12:53 PM Ethan McCue <ethan at mccue.dev> wrote:

> 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/cfe48103/attachment-0001.htm>