RFR: 8295803: Console should be usable in jshell and other environments [v7]
Alan Bateman
alanb at openjdk.org
Tue Dec 6 12:11:08 UTC 2022
On Tue, 6 Dec 2022 07:35:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:
> 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".
-------------
PR: https://git.openjdk.org/jdk/pull/11421
More information about the security-dev
mailing list