Some JDBC drivers returning runtime errors during system scans the jars in the classpath.

Some Progress DataDirect for JDBC drivers returning runtime errors during system scans the jars in the classpath. Why does aggressive pre-loading of classes in DataDirect JDBC drivers sometimes cause "java.lang.NoClassDefFoundError"?

Mar 17, 2021
Knowledge

Title

URL Name

Some-JDBC-drivers-returning-runtime-errors-during-system-scans-the-jars-in-the-classpath

Article Number

000200429

Environment

Product: Progress DataDirect for JDBC Version: 6.0 OS: Java Database: All supported databases Application: All supported applications

Question/Problem Description

Some Progress DataDirect for JDBC drivers returning runtime errors during system scans the jars in the classpath.
Why does aggressive pre-loading of classes in DataDirect JDBC drivers sometimes cause "java.lang.NoClassDefFoundError"?

Steps to Reproduce

Clarifying Information

No errors occur connecting or running queries through the drivers.

Error Message

When Progress DataDirect builds the drivers, we incorporate required third-party libraries. We do this by means of "shading", where we alter the package name so that there are no potential conflicts when the application also uses the same component, but a different version. Also, we execute code to minimize the total size of the driver jar. This code walks through the classes, looking for internal references, and removes any classes (and even in some cases methods) that are not used. There are some limitations with automated methods like this, as some classes are dynamically loaded, so we must maintain a list of exceptional cases. Because Java is a dynamically-loaded language, we must also be aware of transitive dependencies. Perhaps a particular class is not required, but removing it means that another class which bases some definitions on it will fail. In this particular case also, even though there is no direct reference, we must keep the indirectly-referenced class. We never expect that indirect class to be explicitly loaded, because it may also have indirect references which have been excluded. On occasion, aggressive class loaders run afoul of this pattern, but there is not a safe way to avoid it without rewriting the third-party library. There is a second, more common reason however, why most classes are not removed from third-party jars even though they are not referenced. While we do shade the package names, we use a consistent mechanism for doing so. And we recognize that more than one of our drivers may be executing in the JVM at the same time. Particularly this is true when working with HDP, or when our customers use our drivers in integration products. Because we use a consistent package renaming, we keep most classes in the third-party jars because while one driver may not use them, another might. And while the first driver may not also include another component that is referenced, the second one might. By doing this, while a single driver might be slightly larger than absolutely necessary, in instances where our customers use many drivers, it adds up to a considerable savings in memory, since multiple drivers can share the same components. The solution is that the classloader should be configured to ignore errors on classes that it cannot load because of transitive dependencies.

Defect Number

Enhancement Number

Cause

Resolution

Workaround

Notes

Keyword Phrase

Last Modified Date

3/17/2021 2:24 PM

Some JDBC drivers returning runtime errors during system scans the jars in the classpath.

Files(0)

Was this article helpful?

Was this article helpful?

Some JDBC drivers returning runtime errors during system scans the jars in the classpath.

Information

Related Articles