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

Reply via email to