RFR: 8295803: Console should be usable in jshell and other environments [v7]

Naoto Sato naoto at openjdk.org
Tue Dec 6 18:13:21 UTC 2022

On Tue, 6 Dec 2022 06:19:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>>   Fixed the copyright year
> src/java.base/share/classes/java/io/Console.java line 99:
>> 97:  */
>> 98: 
>> 99: public class Console implements Flushable
> Should we perhaps `seal` this class and only `permit` `ProxyingConsole` to `extend` it?

Right. Will address it after this PR.

> src/java.base/share/classes/java/io/Console.java line 615:
>> 613:                 var consModName = System.getProperty("jdk.console",
>> 614:                         JdkConsoleProvider.DEFAULT_PROVIDER_MODULE_NAME);
>> 615:                 return ServiceLoader.load(JdkConsoleProvider.class).stream()
> Are we intentionally using thread context classloader (which can be different depending on which caller ends up first accessing/initializing the `java.io.Console` class) to load these services?
> I initially thought that `java.io.Console` might be used/initialized early in the bootstrap process of Java so the classloader could perhaps be deterministic, but running a trivial Java application with `-verbose:class` shows that `java.io.Console` doesn't get instantiated during the launch, so that leaves this code to "first access wins" situation and maybe an "incorrect" context classloader which doesn't have access the configured `jdk.console` module may end up causing this code to default to `java.io.Console`?
> public class Hello {
> 	public static void main(final String[] args) {
> 	}
> }
> java -verbose:class Hello.java
> Instead, should we perhaps use the ModuleLayer to find this configured module and then use its classloader to load the `JdkConsoleProvider` service provider? Something like:
> final Optional<Module> mod = ModuleLayer.boot().findModule(consModName);
> // ... if not present default to java.io.Console else use the module's classloader to try and load the JdkConsoleProvider
> return ServiceLoader.load(JdkConsoleProvider.class, mod.get().getClassLoader()).stream()......

Changed it to use the boot layer `ServiceLoader.load(ModuleLayer.boot(), JdkConsoleProvider.class)`

> src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java line 113:
>> 111:         public JdkConsoleImpl() {
>> 112:             try {
>> 113:                 terminal = TerminalBuilder.builder().build();
> The `java.io.Console` in its static initialization code has some logic to determine the `Charset` to use. Should that same `Charset` (or logic) be used here to build the terminal? Something like `TerminalBuilder.builder().encoding(fooBarCharset).build();`.

Initially, I thought of having charset as an argument to the constructor but realized jline would delve into the platform and figure out the same encoding, so I omitted it. However now I realized that the user could specify the standard out encoding via the `stdout/err.encoding` system property. So I revived the charset argument, as in your suggestion.


PR: https://git.openjdk.org/jdk/pull/11421

More information about the security-dev mailing list