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.forums2...@gmail.com >> <mailto:jai.forums2...@gmail.com>> 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 https://github.com/quarkusio/quarkus/issues/7079. There's anyway a workaround for it https://github.com/quarkusio/quarkus/pull/7089 so it's not that big an issue. -Jaikiran
