Make name of mssql-jdbc_auth DLL stable or configurable

[Chrriis]

Driver version

Provide the JDBC driver version (e.g. 11.1.2).

Client Operating System

Windows

Problem description

The mssql-jdbc_auth DLL used for Windows authentication does not have a stable name. In older versions of the driver, the name was "sqljdbc_auth.dll". Now it has names like "mssql-jdbc_auth-11.1.2.x64-preview.dll", "mssql-jdbc_auth-11.1.2.x86-preview.dll".

We have several tools that process resources and they need stable names. The best example to illustrate the issue is that we have an installer where it is time consuming to list resources. Once listed, you don't want names to change or you have to recreate that list. Moreover, we ship both 32-bit and 64-bit versions, and the trees of resources are exactly the same (so that we can invoke the installer build on both mirror trees). Because of that DLL whose name changes also based on the architecture, we cannot have matching trees. And unlike JAR files where we can rename to remove version numbers from names, DLLs cannot be renamed or else it cannot link...

The fix would be to stabilize the name of that DLL (no version number, no arch, no "preview" indicator) as it was before or allow the user to specify the name to look for (e.g. using a system property).

[lilgreenbird]

hi @Chrriis
The old driver versions used to be named sqljdbc that's why everything had that prefix. When we moved to open source the driver was renamed to mssql-jdbc. At some point we decided we need to version the auth DLL that's why the version was added and the driver does check to make sure the matching version is used now. Generally the DLL doesn't change much so is the same in new releases but sometimes we do have to add or change the native code there so that is why it needs versioning.

Moving forward we are looking to deprecate the DLL and have all that functionality in the driver in java only however we are waiting to get support for a missing piece from a dependent library.

[Chrriis]

Hi @lilgreenbird, thanks for your answer.

I understand you want to version the DLL, but it means that the x32 DLL has a different name than x64, which has a different name than the next version, etc. It creates many problems, because these resources cannot be renamed by the user: linking would fail. The problem is not that the content of the DLL changes or not, the problem is that the name is not the same for all versions and shipping that DLL is the responsibility of us the users.

Other libraries that have such DLL generally bundle all of them in the JAR, extract them to a temporary directory at run time. Users don't have to explicitly add them to their installed structure. And for the other libraries that don't bundle them in the JAR, they don't have a name that changes depending on the version/architecture/release_state.

A simple enhancement that would allow us to use the Microsoft driver could be to change the declaration of the AUTH_DLL_NAME as such:

static final String AUTH_DLL_NAME;
static {
    String name = System.getProperty("mssql-jdbc_auth-DLL-name");
    AUTH_DLL_NAME = name != null? name: "mssql-jdbc_auth-" + SQLJdbcVersion.major + "." + SQLJdbcVersion.minor + "."
            + SQLJdbcVersion.patch + "." + Util.getJVMArchOnWindows() + SQLJdbcVersion.releaseExt;
}

That way, we would be able to stabilize the name.

I hope you can make such a change for 11.1.x, otherwise this is yet another roadblock that prevents us from transitioning from JTDS.

[lilgreenbird]

That is an interesting concept about bundling the DLL in the jar do you have an examples of where this is done so we can take a look? Thanks for the suggestion I've added this enhancement request into our backlog it will be considered when we do planning for the next semester.

[Chrriis]

Hi @lilgreenbird

Here are 2 examples that auto-extract the libraries: SWT and JNA.

SWT:
https://github.com/eclipse-platform/eclipse.platform.swt/blob/b3186112a06b8383fd3bfbd4555aa4e5fa3ac23a/bundles/org.eclipse.swt/Eclipse%20SWT%20PI/common/org/eclipse/swt/internal/Library.java#L336

JNA:
https://github.com/java-native-access/jna/blob/bf60e51eace6dffa18548019e2ba398ff84904ef/src/com/sun/jna/Native.java#L1174

In the meantime, could you please add the simple system property trick to be able to configure the DLL name? I have been waiting for more than 2 years for bug #1196 to be fixed, and now I am not able to push this updated version to our full test suite because of this limitation...

[laeubi]

It would also be interesting to embeds those DLLs in the jar and add appropriate OSGi native headers so they can be found automatically.

I already tried to find out if it is even suitable to embeds the DLL because they have a different license, so it would be great to get an official statement if one has to read the license, e.g. would it be allowed to include the DLL in a product in a jar and ship that jar to the user, or do one need to ask the user do download and install the DLL itself?

[Chrriis]

Another case that loads a DLL from JAR file.

FlatLaf:
https://github.com/JFormDesigner/FlatLaf/blob/main/flatlaf-core/src/main/java/com/formdev/flatlaf/util/NativeLibrary.java#L86

[laeubi]

@Chrriis I think the most flexible way would be if the DLL would not be deployed as "dll" to central but (also) as a jar containing the DLL, then one can simply add both maven dependencies and we can add code that scans the classpath for the DLL (it should then already knows the name) and probably extract/use it then.

[slachiewicz]

and also here https://github.com/fusesource/jansi/blob/master/src/main/java/org/fusesource/jansi/internal/JansiLoader.java#L163