RFR: 8284161: Implementation of Virtual Threads (Preview)

[ExE Boss]

On Wed, 13 Apr 2022 09:49:04 GMT, Daniel Fuchs <dfuchs at 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