Finalising the on-ramp feature

[david Grajales]

Hi Gavin. Hope you are doing well.
I would like to suggest a last change if allowed, hoping it's not it to be
not full of inconveniences.

What about implicitly importing all static methods on java.lang (not sure
about only for compact compilation units of a general)? that would make
easier and shorter simple operations like parsing strings to any number
type, use the Math package and so on, it would be still allow for
Class.method() when preferred/needed without change in the source code (For
example if one would want to use a concrete implementation of max()), I
know there are some clarity issues (where does this method comes from?"
)besides and to be honest, it's very unlikely people will use alternatives
for what java lang offers in most cases unless they need very specific
requirements, so further ambiguity is a less concern IMHO, far less
disruptive in this regard than star imports and import module.

It's a small quality of life improvement, specially for small things and
students.

Best regards and best wishes to all Java development team.

El mar, 21 ene 2025 a la(s) 8:28 a.m., Gavin Bierman (
gavin.bierman at oracle.com) escribió:

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