On Wed, 13 Apr 2022 11:38:55 GMT, ExE Boss <d...@openjdk.java.net> wrote:
>> 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);
> Thanks - the same issue appears with `BufferedWriter`/`Writer`.
Right. I think we can reduce this to the case where a BufferedReader is not
subclassed, and it wraps an InputStreamReader or FileReader that have not been
subclassed. Similarly the case where a BufferedWriter is not subclassed and it
wraps an OutputStreamWriter or FileWriter that have not been subclassed.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8166
