Finalising the on-ramp feature

[david Grajales]

Perfectly understandable. Thanks Brian.

Best regards.

El mar, 21 de ene de 2025, 11:04 a. m., Brian Goetz <brian.goetz at oracle.com>
escribió:

> This is an idea that we discussed and rejected (with extreme prejudice!)
> very early on the process.  It effectively takes every static method in
> java.lang (including what will probably seem like a random grab bag of
> things like runFinalizersOnExit) and elevates them "into the language."
> (THen, it creates a perverse incentive to put MORE stuff in java.lang just
> to get the importing.)  This is the very opposite of what we want to
> achieve here.
>
>
> On 1/21/2025 10:54 AM, david Grajales wrote:
>
> 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/0118037e/attachment-0001.htm>