On Wed, 13 Apr 2022 09:49:04 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
>>> Not sure if that even matters - but there will be a slight change of
>>> behaviour here if `InternalLock.CAN_USE_INTERNAL_LOCK` is ever `false`.
>>> Instead of synchronizing on `in`, the `BufferedReader` will synchronize on
>>> `this`.
>>
>> Good! We can change this so that depends on whether BufferedReader is
>> extended and whether the given Reader is trusted. It's not clear if anyone
>> could reliably depend on undocumented behavior like this but we have to be
>> cautious at the same time.
>
> Thanks - the same issue appears with `BufferedWriter`/`Writer`.
The solution is to add the `private` constructor:
private Reader(Object fallbackLock, Void internal) {
// assert fallbackLock != null;
// use InternalLock for trusted classes
Class<?> clazz = getClass();
if (clazz == InputStreamReader.class
|| clazz == BufferedReader.class
|| clazz == FileReader.class
|| clazz == sun.nio.cs.StreamDecoder.class) {
this.lock = InternalLock.newLockOr(fallbackLock);
} else {
this.lock = fallbackLock;
}
}
to `Reader` (and an equivalent `private` constructor to `Writer`).
---
The `protected` `Reader` constructors can then be changed to:
protected Reader() {
this(this, null);
}
and
protected Reader(Object lock) {
this(Objects.requireNonNull(lock), null);
}
---
Doing so will allow this change to be reverted:
Suggestion:
super(in);
-------------
PR: https://git.openjdk.java.net/jdk/pull/8166
