Message-ID: <gh-pgjdbc-pgjdbc-4155@github.com>
From: "BonusLord (@BonusLord)" <noreply+BonusLord@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Thu, 04 Jun 2026 19:01:49 +0000
Subject: [pgjdbc/pgjdbc] issue #4155: Using driver nulls out the context classloader of shared threads in ForkJoinPool.commonPool()
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Id: 5925424
X-GitHub-Author-Login: BonusLord
X-GitHub-Issue: 4155
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-State: closed
X-GitHub-Type: issue
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/4155
Content-Type: text/plain; charset=utf-8

**Describe the issue**
When the PostgreSQL JDBC driver is first initialized / used, logic within `LazyCleanerImpl` submits an async task to `ForkJoinPool.commonPool()` which calls `Thread.currentThread().setContextClassLoader(null);`. This permanently nulls out the context classloader of a random thread in the commonPool, which can affect the behavior of subsequent async tasks that happen to execute on the same commonPool thread that was "poisoned" by the logic in `LazyCleanerImpl`.

In my case, this causes errors in subsequent async tasks that are using the reflections8 library to discover classes, because the behavior of methods in the reflections8 library is sensitive to the context classloader of the calling thread. This breaks various functionality in our Java application.

**Driver Version?** 
42.7.11

**Java Version?**
11.0.18

**To Reproduce**
Steps to reproduce the behavior:
- Make a query to a postgres DB using the JDBC library
- Submit a bunch of tasks to `ForkJoinPool.commonPool()` which just log the name and the context classloader of the current thread
- Observe that a null context classloader is reported by some of the log messages

**Expected behaviour**
Using the postgres JDBC driver should not permanently alter the state of threads in the JVM's globally-shared common ForkJoinPool.