DriverManager.isDriverAllowed has an unintentional side-effect?

Jaikiran Pai jai.forums2013 at
Thu Feb 13 03:13:14 UTC 2020

Hello Lance,

On 13/02/20 12:22 am, Lance Andersen wrote:
> Hi Jaikiran
>> On Feb 10, 2020, at 10:05 PM, Jaikiran Pai <jai.forums2013 at
>> <mailto:jai.forums2013 at>> wrote:
>> Hello Lance,
>> On 11/02/20 2:05 am, Lance Andersen wrote:
>>> Hi Jaikiran
>>>> Should this check in the isDriverAllowed, instead use "false" and not
>>>> trigger the intialization of the class?
>>> As I mentioned above, this dates back to the very early days of JDBC
>>> and JDK 1.2.  Any changes in this area could be quite disruptive and
>>> would require extensive testing. 
>> That's a valid reason and I understand the unwillingness to change this.
>> On a related note, the ensureDriversInitialized method right now gets
>> run once per JVM. However, given that the rest of the DriverManager
>> deals with per classloader Driver(s), would it be right to somehow make
>> ensureDriversInitialized run once per classloader instance? That way,
>> this issue won't show up in first place, given that
>> ensureDriversInitialized would have ensured that any drivers available
>> in that classloader would have been loaded during the first call from
>> class A (in that example).
> This behavior also  dates back as well to JDK 1.2 and could be
> disruptive given how many years this code has been in place.
> It might be worth us  considering an alternative to DriveManager at
> some point allowing us to address some of  these limitations. 

Thank you for checking, Lance. I understand why it's not desirable to
change it at this point.

> In the meantime, you could choose to use a DataSource vs a Driver
> which if the DataSource is  implemented correctly does not rely on
> DriverManager.
For context, I happened to notice these issues in the DriverManager when
I was looking into this Quarkus reported issue There's anyway a
workaround for it so it's
not that big an issue.


More information about the core-libs-dev mailing list