On Tue, 6 Dec 2022 07:35:44 GMT, Jaikiran Pai <j...@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
