shoudln't we annotate that header as well? I guess mima will complain then? But at least write a note on top of it?

I'll add a comment there.

By annotate you mean add it to mima exclusions?

I think this constructor is actually being re-added here so we can fix binary compatibility which was broken after we re-add DBApi dependency. In other words, instead of adding the new constructor to mima exclusions, @gmethvin is re-adding this constructor.

well what I meant is that we either tell it's deprecated (since it's not in master) or we also add the constructor to master by adding a note that it doesn't initalize the database and somebody needs to do it by itself (actually the second note should be there anyway)

The dependency on DBApi is just a hack here because the constructor relies on global state, so we could add back the old constructor in master too. The dependency could be fulfilled in another way.

We probably want to refactor how this works in master anyway. There is no direct reason why this needs a dependency on DBApi. It's quite possible to have an alternative implementation that doesn't use JNDI at all, in which case the DBApi dependency is confusing and unnecessary.

Usually the way I handle this is to have a component that wraps the global state and is aware of whether it's initialized. In this case we could just make a JNDI class that does this and is injected where it's needed.