Finalising the on-ramp feature

[David Alayachew]

Hmmmm.

I see doing the module import as a small enough lift. Same as the amount of
lift needed to add void main().

For me, the big goal of this jep is to remove the major road stops on the
on-ramp. Forcing people to add a module import seems small enough to be
acceptable.

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

> My phrasing is based on how Brian phrased it
>
> > 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.
>
> To be more concrete: both code samples A and B are valid "locutions"
>
> A:
> void main() {
>     var message = "Hello, world";
>     IO.println(message);
> }
>
> B:
> void main() {
>     var message = List.of("Hello", "world");
>     IO.println(message);
> }
>
> But B cannot be evolved into a named class without either an extra import.
> A, however, can.
>
> What I thought was notable was that, in the learning paths that make use
> of classes like List, you have to have import module java.base; as part
> of the translation to named class. Where having IO in java.lang helps
> make that transition in a world where you do not have import module
> java.base;
>
> My imagined reasoning is that it allows for both paths that do and do not
> cover classes outside of java.lang to coexist. If you stay within what
> would be available sans the import module java.base; then you don't need
> to explain it until much later. If you use ArrayList you can at least
> delay the import module explanation a little later. With that thought I'm
> satisfied.
>
> On Tue, Jan 21, 2025 at 2:32 PM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> 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/083f1fb1/attachment.htm>