RFR: 8342936: Enhance java.io.IO with parameter-less println() and readln() [v3]

Jaikiran Pai jpai at openjdk.org
Wed Oct 30 08:20:06 UTC 2024


On Tue, 29 Oct 2024 08:13:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR is simply adding parameter-less `java.io.IO.{println(),readln()}`, with the (hopefully) obvious semantics, plus the corresponding wiring to make those work. This may become part of JEP 495:
>> https://openjdk.org/jeps/495
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test for Console.readln/readLine, ensuring the proper methods are called.

src/java.base/share/classes/java/io/Console.java line 184:

> 182:      */
> 183:     @PreviewFeature(feature = PreviewFeature.Feature.IMPLICIT_CLASSES)
> 184:     public Console println() {

Hello Jan, with the introduction of the simplified `java.io.IO` class, some of whose APIs are wrappers around the `java.io.Console` class APIs, it's understandable that we will start seeing new methods being introduced on the `Console` class.

For this specific new `println()` method on the `Console` class, do you think this method will/should be introduced irrespective of the `IO` class usage? In other words, considering a theoretic case where there may be a situation to abandon the implicit classes preview feature or do it in a different way, would we still want this `println()` method to stay on the `Console`? If yes, then perhaps we should drop the `@PreviewFeature` annotation from this new method and introduce it as a regular new API? Same question for the new `readln()` method on the `Console`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21693#discussion_r1822089736


More information about the kulla-dev mailing list