On Tue, 7 May 2024 11:00:52 GMT, Pavel Rappo <pra...@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

Reply via email to