Thursday, January 17, 2013 3:16 PM
we use Java TFS SDK 10.1.0 without native libraries in our application and it works fine. Now we try to update to TFS SDK 184.108.40.2062 and TFSTeamProjectCollection.getVersionControlClient() throws following exception:
As I understood from similar threads this is because we do not use native libraries (we do not set VM property com.microsoft.tfs.jni.native.base-directory). Btw when I set this property everything works fine.
I would like to know whether we really need include native libraries in our application. Is there possibility not to use native libraries when we use functionalities which do not need them?
Do you plan to avoid native libraries at all in future Java TFS SDK?
Thursday, January 24, 2013 1:31 AMModerator
I'm sorry, no, native libraries are indeed required. Java lacks significant functionality that is required for operation. Seemingly simple operations like setting a file read-only or writable or getting and setting environment variables have varying levels of support on different Java specifications and virtual machine implementations. Even getting the computer name is a complicated proposition on some platforms.
Some of the required features that are implemented by our natives libraries are:
- Server authentication (Kerberos on all platforms, NTLM on Windows)
- Filesystem ACLs (Windows)
- Filesystem extended attributes (Mac OS)
- Creating symbolic links (Unix)
- Getting / setting file system attributes, permissions, etc
- IPC for synchronization with other TFS clients
- Getting the hostname
In addition, we add some advanced features using native libraries that are helpful but not necessarily required:
- Keychain access on Mac OS
- DPAPI access on Windows
Therefore, we do not have plans to operate without native libraries.