RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]

[Alan Bateman]

On Wed, 13 Apr 2022 11:38:55 GMT, ExE Boss <duke at 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