Support custom ThreadFactory.

[hstyi]

This PR adds support for a custom ThreadFactory in JSch. Users can now provide their own ThreadFactory, which is particularly useful in Java 21, as it allows leveraging virtual threads for better concurrency and resource management.

[sonarqubecloud]

Quality Gate failed

Failed conditions
5.7% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[norrisjeremy]

So a few suggestions:

1. Instead of using Executors.defaultThreadFactory(), let's instead just use a simple lambda based Thread::new as the default, as this will functionally make this a noop change (since Executors.defaultThreadFactory() sets a Thread name, etc.).
2. Let's initialize the new threadFactory property to a non-null value and then disallow users from ever setting it to null via setThreadFactory(), so that we never have to explicitly check for null in getThreadFactory().

I would also caution against using JSch with virtual threads, at least unless you are using the new Java 24 release that came out earlier this week, since I suspect you would likely encounter problems.
JSch makes significant use of synchronized style locking, that until the new Java 24 release results in carrier thread pinning when combined with virtual threads, which in turn can lead to difficult to diagnose deadlocks.

[norrisjeremy]

Suggested change

	private ThreadFactory threadFactory = null;
	private ThreadFactory threadFactory = Thread::new;

[norrisjeremy]

Suggested change

	public void setThreadFactory(ThreadFactory threadFactory) {
	this.threadFactory = threadFactory;
	}
	public void setThreadFactory(ThreadFactory threadFactory) {
	this.threadFactory = Objects.requireNonNull(threadFactory);
	}

[norrisjeremy]

Suggested change

	public ThreadFactory getThreadFactory() {
	if (threadFactory == null)
	threadFactory = Executors.defaultThreadFactory();
	return threadFactory;
	}
	public ThreadFactory getThreadFactory() {
	return threadFactory;
	}

[norrisjeremy]

Suggested change

	import java.util.Hashtable;
	import java.util.Map;
	import java.util.Vector;
	import java.util.concurrent.Executors;
	import java.util.concurrent.ThreadFactory;
	import java.util.Hashtable;
	import java.util.Map;
	import java.util.Objects;
	import java.util.Vector;
	import java.util.concurrent.ThreadFactory;

[norrisjeremy]

Also, I am wondering if would it be better to put the new ThreadFactory property in the Session class instead of the JSch class, since the only places that are creating Thread objects are within the Session class or within various Channel implementations, which are strongly bound to a Session object in the first place?
What do you think?

[hstyi]

@norrisjeremy Thank you for your reply.

1. We can change synchronized to ReentrantLock.
2. Putting threadFactory in the Session class does allow for more granular control.

In addition, JDK 21 is being used more and more, especially in high IO usage scenarios where virtual threads are very advantageous.