RFR: 8305457: Implement java.io.IO

Rémi Forax forax at openjdk.org
Tue May 7 12:21:53 UTC 2024


On Tue, 7 May 2024 11:00:52 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 74:
>> 
>>> 72: 
>>> 73:     @Override
>>> 74:     public String readln(String prompt) {
>> 
>> this code can be simplified using an early return (and the body of the try/catch can be reduced so it is more clear which statement can cause the IOException)
>> 
>>         synchronized (writeLock) {
>>             synchronized(readLock) {
>>                 if (!prompt.isEmpty()) {
>>                     pw.print(prompt);
>>                     pw.flush(); // automatic flushing does not cover print
>>                 }
>>                char[] array;
>>                 try {
>>                     array = readline(false);
>>                 } catch (IOException x) {
>>                     throw new IOError(x);
>>                 }
>>                 if (array != null) {
>>                     return new String(array);
>>                 }
>>             }
>>         }
>>         return null;
>
> This method started as a copy of `readLine`. In its current form, it's very evident how `readln` differs from `readLine`, and I would leave it this way for now. If the feature is standardised, we could refactor both methods together, as you suggested.
> 
> If the `java.io.IO` part of the feature or the feature itself is withdrawn, then we could consider refactoring the existing `readLine`. Does it make sense?

I do not think the step to "standardise" a preview feature exists ? When a preview feature becomes a released feature, the code is very lightly edited, at least it this is my experience. 

You can change both readln and readLine and if `java.io.IO` is removed, at least the code of readLine() will be

>> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 88:
>> 
>>> 86:         @Override
>>> 87:         public JdkConsole println(Object obj) {
>>> 88:             writer().println(obj);
>> 
>> the result of 'writer()' can be stored in a local variable (printing code are not JITed as often as the rest of the codes)
>
> I assume it's about performance. If so, I would defer any performance-related tweaks until they are necessary. Interactive reading from console does not sound like something requiring that level of performance tweaking.

yes, let see what @cl4es will say when he will test the time to print "hello world"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592385449
PR Review Comment: https://git.openjdk.org/jdk/pull/19112#discussion_r1592387034


More information about the core-libs-dev mailing list