When used in a Java EE / Jakarta EE environment, LdapClient can trigger a memory leak due to the "auto-reconnect" behaviour of com.sun.jndi.ldap.Connection.

This was observed in Apache Tomcat when using JNDI to connection to an LDAP server for authentication and authorisation.

The problematic sequence of events is as follows:
- Tomcat creates the appropriate DirContext ensuring that the ThreadContextClassLoader (TCCL) is set to a shared, Tomcat provided class loader. This ensures that the thread created by com.sun.jndi.ldap.Connection uses that TCCL.
- Web applications (each web application has its own class loader) use this Connection instance, via a pooling mechanism, for authentication
- Something causes the Connection to close
- The next web application to try and use the Connection triggers reconnection
- The thread created by Connection at this point uses the web application class loader as the TCCL loader. This creates a potential memory leak as it pins the web application class loader in memory even if the web application is undeployed.

We can, and will, work around this in Tomcat by ensuring that all uses of Connection are wrapped by code that sets an appropriate TCCL just in case.

It would be helpful if this could be addressed in the JRE. Any of the following options, or an equivalent, would work.
- Set the TCCL of the thread created by Connection to the class loader used to load the Connection class
- Set the TCCL of the thread created by Connection to ClassLoader.getSystemClassLoader()