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