New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JNA is not optional when testing on windows #11360
Labels
Comments
jaymode
added a commit
to jaymode/elasticsearch
that referenced
this issue
May 27, 2015
Today, JNA is a optional dependency in the build but when running tests or running with mlockall set to true, JNA must be on the classpath for Windows systems since we always try to load JNA classes when using mlockall. The old Natives class was renamed to JNANatives, and a new Natives class is introduced without any direct imports on JNA classes. The Natives class checks to see if JNA classes are available at startup. If the classes are available the Natives class will delegate to the JNANatives class. If the classes are not available the Natives class will not use the JNANatives class, which results in no additional attempts to load JNA classes. Additionally, all of the JNA classes were moved to the bootstrap package and made package private as this is the only place they should be called from. Closes elastic#11360
jaymode
added a commit
to jaymode/elasticsearch
that referenced
this issue
May 27, 2015
Today, JNA is a optional dependency in the build but when running tests or running with mlockall set to true, JNA must be on the classpath for Windows systems since we always try to load JNA classes when using mlockall. The old Natives class was renamed to JNANatives, and a new Natives class is introduced without any direct imports on JNA classes. The Natives class checks to see if JNA classes are available at startup. If the classes are available the Natives class will delegate to the JNANatives class. If the classes are not available the Natives class will not use the JNANatives class, which results in no additional attempts to load JNA classes. Additionally, all of the JNA classes were moved to the bootstrap package and made package private as this is the only place they should be called from. Closes elastic#11360
jaymode
added a commit
that referenced
this issue
May 27, 2015
Today, JNA is a optional dependency in the build but when running tests or running with mlockall set to true, JNA must be on the classpath for Windows systems since we always try to load JNA classes when using mlockall. The old Natives class was renamed to JNANatives, and a new Natives class is introduced without any direct imports on JNA classes. The Natives class checks to see if JNA classes are available at startup. If the classes are available the Natives class will delegate to the JNANatives class. If the classes are not available the Natives class will not use the JNANatives class, which results in no additional attempts to load JNA classes. Additionally, all of the JNA classes were moved to the bootstrap package and made package private as this is the only place they should be called from. Closes #11360
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The JNA library is listed as optional in the pom file but when running tests in another project without the library, we still try to load it and loading fails with a
ClassNotFoundException
:which then cascades into:
This seems to be provoked only on Windows by the
Natives#tryVirtualLock
method currently.The text was updated successfully, but these errors were encountered: