Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8295803: Console should be usable in jshell and other environments #11421

Closed
wants to merge 27 commits into from

Conversation

naotoj
Copy link
Member

@naotoj naotoj commented Nov 29, 2022

This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. System.console() now returns a Console implementation based on jdk.internal.le terminal by default, or jshell implementation if available. A corresponding CSR has been drafted.


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change requires a CSR request to be approved

Issues

  • JDK-8295803: Console should be usable in jshell and other environments
  • JDK-8297226: Console should be usable in jshell and other environments (CSR)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421
$ git checkout pull/11421

Update a local copy of the PR:
$ git checkout pull/11421
$ git pull https://git.openjdk.org/jdk pull/11421/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 11421

View PR using the GUI difftool:
$ git pr show -t 11421

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/11421.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Nov 29, 2022

👋 Welcome back naoto! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Nov 29, 2022

@naotoj The following labels will be automatically applied to this pull request:

  • core-libs
  • kulla
  • security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added security security-dev@openjdk.org core-libs core-libs-dev@openjdk.org kulla kulla-dev@openjdk.org csr Pull request needs approved CSR before integration labels Nov 29, 2022
@naotoj naotoj marked this pull request as ready for review November 30, 2022 16:56
@openjdk openjdk bot added rfr Pull request is ready for review and removed csr Pull request needs approved CSR before integration labels Nov 30, 2022
@mlbridge
Copy link

mlbridge bot commented Nov 30, 2022

Copy link
Member

@JimLaskey JimLaskey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good otherwise. Add tests.

src/java.base/share/classes/java/io/Console.java Outdated Show resolved Hide resolved
Copy link
Member

@JimLaskey JimLaskey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@openjdk
Copy link

openjdk bot commented Dec 1, 2022

@naotoj This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8295803: Console should be usable in jshell and other environments

Reviewed-by: jlaskey, alanb

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 35 new commits pushed to the master branch:

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Dec 1, 2022
@@ -93,7 +96,7 @@
* @since 1.6
*/

public final class Console implements Flushable
public class Console implements Flushable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we perhaps seal this class and only permit ProxyingConsole to extend it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. Will address it after this PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jaikiran
Copy link
Member

jaikiran commented Dec 6, 2022

Hello Naoto, the class level javadoc of java.io.Console currently specifies synchronization expectations in the context of multithreaded use:

Read and write operations are synchronized to guarantee the atomic
completion of critical operations; therefore invoking methods
{@link #readLine()}, {@link #readPassword()}, {@link #format format()},
{@link #printf printf()} as well as the read, format and write operations
on the objects returned by {@link #reader()} and {@link #writer()} may
block in multithreaded scenarios.

So the Console instance returned from System.console(), thus far, follows these semantics. However, with the change proposed in this PR, the default implementation will now be the jline backed JdkConsoleImpl implementation. From what I can see there, we don't seem to have any similar guarantees around multithreaded access. Do we need similar locking constructs in that implementation to guarantee/verify it works as per the expectations of java.io.Console API?

While we are at it, the Console class level javadoc also states:

If the virtual machine is started from an
interactive command line without redirecting the standard input and
output streams then its console will exist and will typically be
connected to the keyboard and display from which the virtual machine
was launched.

With this proposed change, to by default use the jline backed implementation, would we need to reword/update that javadoc?

@AlanBateman
Copy link
Contributor

So the Console instance returned from System.console(), thus far, follows these semantics. However, with the change proposed in this PR, the default implementation will now be the jline backed JdkConsoleImpl implementation. From what I can see there, we don't seem to have any similar guarantees around multithreaded access. Do we need similar locking constructs in that implementation to guarantee/verify it works as per the expectations of java.io.Console API?

As it happens I was chatting with Naoto about this area yesterday. There are effectively two Console implementations, the base implementation in Console, and the subclass in ProxyingConsole. When using ProxyingConsole then the state/implementation in the superclass isn't used. So either the locks are exposed to the subclass or there is a bit more surgery done so there are two subclasses, each with their own read and write locks. Subclasses might be cleaned as there is state in Console that is not interesting for the new implementation.

With this proposed change, to by default use the jline backed implementation, would we need to reword/update that javadoc?

That is a good observation, instead of "will typically not have a console" then it should probably say "may not have a console".

@naotoj
Copy link
Member Author

naotoj commented Dec 6, 2022

Provided separate independent locks in ProxyingConsole for now. Later it can be re-org'ed as Alan suggested for cleaner implementation/interface separation.


@Override
public void close() throws IOException {
r.close();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Console specifies that the invoking close on the Reader and Writer does not close the underlying stream. So I think this close (and WrappingWriter::close) need to be a no-op too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. Made them as no-op.

@@ -208,6 +208,13 @@ public PrintWriter(String fileName) throws FileNotFoundException {
false);
}

/* package private constructor specific to ProxyingConsole */
PrintWriter(Writer out, Object lock) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This constructor looks fine but maybe the comment should just say that it allows the lock object to be provided rather than mentioning ProxyingConsole here.

@AlanBateman
Copy link
Contributor

Thanks for the updates, I don't have any more comments. I think should create a follow-up issue to "hollow out" Console and have two separate implementations/subclasses. I think that would make it much cleaner rather than one implementation extending the other as we have now.

@naotoj
Copy link
Member Author

naotoj commented Dec 7, 2022

/integrate

@openjdk
Copy link

openjdk bot commented Dec 7, 2022

Going to push as commit 8a9911e.
Since your change was applied there have been 35 commits pushed to the master branch:

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Dec 7, 2022
@openjdk openjdk bot closed this Dec 7, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Dec 7, 2022
@openjdk
Copy link

openjdk bot commented Dec 7, 2022

@naotoj Pushed as commit 8a9911e.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core-libs core-libs-dev@openjdk.org integrated Pull request has been integrated kulla kulla-dev@openjdk.org security security-dev@openjdk.org
6 participants