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