<p dir="ltr">Perfectly understandable. Thanks Brian. </p>
<p dir="ltr">Best regards. </p>
<br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">El mar, 21 de ene de 2025, 11:04 a. m., Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
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. <br>
<br>
<br>
<div>On 1/21/2025 10:54 AM, david Grajales
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi Gavin. Hope you are doing well.</div>
<div>I would like to suggest a last change if allowed, hoping
it's not it to be not full of inconveniences.</div>
<div><br>
</div>
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.
<div><br>
</div>
<div>It's a small quality of life improvement, specially for
small things and students.
<div><br>
</div>
<div>Best regards and best wishes to all Java development
team.</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">El mar, 21 ene 2025 a la(s)
8:28 a.m., Gavin Bierman (<a href="mailto:gavin.bierman@oracle.com" target="_blank" rel="noreferrer">gavin.bierman@oracle.com</a>)
escribió:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear
Experts,<br>
<br>
With JDK 24 preparations complete, we are now planning our
work for JDK 25 and<br>
in particular the on-ramp JEP. It is our intention to
*finalise* the on-ramp<br>
feature in JDK 25. We are grateful for the feedback that we
have received from<br>
our expert and developer communities - thank you! - and we
have been performing<br>
our own extensive in-house experiments with the preview
feature. Given this, we<br>
propose that we make the following changes/simplifications to
the feature when<br>
it finalizes in JDK 25. <br>
<br>
## 1. Remove the auto-static-import feature and move the `IO`
class<br>
<br>
We had proposed that the static members of a new class `IO`
would automatically<br>
be imported by simple compilation units. This allows the use
of the simple names<br>
`println`, `print`, `readln`, and `read`. Whilst this is very
convenient, it<br>
creates a bump in the on-ramp experience when migrating a
simple compilation<br>
unit to an ordinary compilation unit, which does not
implicitly import these static<br>
methods. This means that when migrating we either add an
explicit static import,<br>
or rewrite all the `println`, `print`, `readln` and `read`
method calls to<br>
qualified calls. <br>
<br>
We have come to the conclusion that the graceful on-ramp
experience is the more<br>
important goal. So, we propose in JDK 25 that (1) we drop the
automatic static<br>
import of the `IO` class by simple compilation units, and (2)
We move the `IO`<br>
class from package `<a href="http://java.io" rel="noreferrer noreferrer" target="_blank">java.io</a>` to
`java.lang`. <br>
<br>
This means that in simple compilation units calls to the `IO`
methods should be<br>
qualified, i.e. `IO.println`, `IO.print`, `IO.readln` and
`IO.read`. However,<br>
when migrating from a simple compilation unit to an ordinary
compilation unit,<br>
no static import declaration will need to be added, nor will
any of these calls<br>
need to be rewritten; the on-ramp experience is simpler. For
example:<br>
<br>
```<br>
// Simple.java<br>
void main() {<br>
IO.println("Hello, world.");<br>
}<br>
```<br>
<br>
is migrated to:<br>
<br>
```<br>
// Ordinary.java<br>
class Ordinary {<br>
void main() {<br>
IO.println("Hello, world.”);<br>
}<br>
}<br>
```<br>
<br>
<br>
## 2. Changes to the `IO` class<br>
<br>
The new `IO` class is intended to contain the most basic
line-oriented I/O<br>
methods for beginners. <br>
<br>
Currently the implementation of the methods of this class are
thin wrappers<br>
around their equivalents in the `Console` class. We propose in
JDK 25 to<br>
decouple `IO` completely from `Console` which we think will
better reflect the<br>
expectation of developers (see, for example,<br>
<a href="https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html" rel="noreferrer noreferrer" target="_blank">https://mail.openjdk.org/pipermail/amber-dev/2024-September/008933.html</a>).<br>
<br>
Thus we propose that `IO` printing and reading are based on
`System.out` and<br>
`System.in`, respectively. <br>
<br>
We do not plan to add other functionality to the `IO` class,
e.g. a `readInt`<br>
method, in JDK 25. We observe:<br>
<br>
1. This JEP is not the final word on improving the on-ramp
experience in Java,<br>
but merely the first step. We can continue to work on this
area in future<br>
JEPs.<br>
<br>
2. I/O and data conversion are, we believe, separate concerns
and, as such, data<br>
conversion doesn't belong in a basic I/O class. Conversion,
and in particular<br>
the related issues around error handling, can be considered
separately,<br>
and given the auto-import of the `java.base` module, we can
easily add<br>
additional utility classes in support of this in future
releases.<br>
<br>
## 3. Revise some terminology<br>
<br>
We're going to replace the term "simple compilation unit" with
"**compact**<br>
compilation unit" in the spec (and replace "simple source
file" with "compact<br>
source file" in the JEP text). Hopefully, "compact" is more
concrete, evocative<br>
terminology (and we have used it elsewhere with records).<br>
<br>
<br>
Comments welcome!<br>
<br>
Thanks,<br>
Gavin </blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div>