Develop Reference

Quickly find if Java was launched from Windows cmd or Cygwin terminal

I have a Java application that will be used both from the Windows Command Prompt and the Cygwin terminal. The program uses and manipulates file paths. It we be very useful to have a sep variable that would be / when the program is launched from Cygwin but \\ when the program is launched from Windows.
Looking here, I'm not sure it will be possible, but I want to ask.
I will post a small, compilable app that shows the issue in a few minutes. For now, I'll just say that I want a set of functions that something like:
// in main
...
String sep = getSeparatorToUse();
...
// member functions
...
private boolean wasLaunchedFromWinCmd()
{
if (<something-here-that-knows-it-was-cmd-not-cygwin>)
return true;
return false;
}//endof: private boolean wasLaunchedFromWinCmd()
private String getSeparatorToUse()
{
if (wasLaunchedFromWinCmd)
return "\\"
return "/"
}//endof: private String getSeparatorToUse()
Thanks #Raphael_Moita. Those are very useful, and I will likely use them in the Linux version of the app that I will be using. #Luke_Lee, I feel dumb not having realized it. I think you two might have solved my problem while I was getting the compilable code ready. There's still one issue when the program run from a batch script - when it is fed a filename from a find command. I hope what I show will illustrate that.
Examples
All examples are as run from Cygwin.
Works: the way most volunteers use the code, just the filename that's in the same directory as the java code.
$ java FileSeparatorExample pic_4.jpg
Here, something will be done with the file,
C:\Users\bballdave025\Desktop\pic_4.jpg
Works: with relative filepaths and spaces in filenames/file paths
$ java FileSeparatorExample pretty\ pictures/pic\ 1.jpg
Here, something will be done with the file,
C:\Users\me\Desktop\pretty pictures/pic 1.jpg
$ java FileSeparatorExample ../pic_5.jpg
Here, something will be done with the file,
C:\Users\me\Desktop\../pic_5.jpg
DOESN'T WORK. Sometimes, the output of a find command will come with the complete filepath in Cygwin/UNIX format:
$ java FileSeparatorExample /cygdrive/c/David/example/pic.jpg
The file:
C:\Users\bballdave025\Desktop\/cygdrive/c/David/example/pic.jpg
doesn't exist
Compilable Code
I'm just cutting down from my original code, so I'm sorry if it seems too big.
/**********************************
* #file FileSeparatorExample.java
**********************************/
// Import statements
import java.io.File;
import java.io.IOException;
public class FileSeparatorExample
{
// Member variables
private static String sep;
public static void main(String[] args)
{
////****** DOESN'T WORK AS DESIRED ******////
sep = java.io.File.separator;
////** I want **////
// sep = getFileSeparator();
String imageToLoad = null;
boolean argumentExists = ( args != null && args.length != 0 );
if (argumentExists)
{
boolean thereIsExactlyOneArgument = ( args.length == 1 );
if (thereIsExactlyOneArgument)
{
imageToLoad = args[0];
}//endof: if (thereIsExactlyOneArgument)
else
{
// do some other stuff
}
}//endof: if (argumentExists)
String filenamePath = getFilenamePath(imageToLoad);
String filenameFile = getFilenameFile(imageToLoad);
imageToLoad = filenamePath + sep + filenameFile;
File f = new File(imageToLoad);
if (! f.exists())
{
System.err.println("The file:");
System.err.println(imageToLoad);
System.err.println("doesn\'t exist");
System.exit(1);
}//endof: if (! f.exists())
System.out.println("Here, something will be done with the file,");
System.out.println(imageToLoad);
}//endof: main
// member methods
/**
* Separates the filename arg into: full path to directory; bare filename
*/
private static String[] splitFilename(String imageToLoad)
{
String[] fileParts = new String[2];
int indexOfLastSep = imageToLoad.lastIndexOf(sep);
boolean fullFilenameHasSeparator = ( indexOfLastSep != -1 );
if (fullFilenameHasSeparator)
{
fileParts[0] = imageToLoad.substring(0, indexOfLastSep);
fileParts[1] = imageToLoad.substring(indexOfLastSep + 1);
}//endof: if (fullFilenameHasSeparator)
else
{
// Use the user's directory as the path
fileParts[0] = System.getProperty("user.dir");
fileParts[1] = imageToLoad;
}//endof: if/else (fullFilenameHasSeparator)
return fileParts;
}//endof: private static String[] splitFilename(String imageToLoad)
/**
* Gives the full path to the file's directory (from the filename arg)
* but not the bare filename
*/
private static String getFilenamePath(String imageToLoad)
{
String[] fileParts = splitFilename(imageToLoad);
return fileParts[0];
}//endof: private static String getFilenamePath(String imageToLoad)
/**
* Gives the bare filename (no path information)
*/
private static String getFilenameFile(String imageToLoad)
{
String[] fileParts = splitFilename(imageToLoad);
return fileParts[1];
}//endof: private static String getFilenamePath(String imageToLoad)
}//endof: public class FileSeparatorExample

You don't need to know which SO is under your Java. If your goal is to find the correct file separator to use, call this:
java.io.File.separator;
Anyway ... to find out which SO java is running over (not sure how cygwin is detected by this), try:
boolean isWindows = System.getProperty("os.name").startsWith("win");

Here is an answer I've come up with that almost answers my original question. It tries to determine the launcher of the Java code based on the filename argument. A big thanks to #Raphael_Moita and #Luke_Lee, who actually pretty much solved my problem. Their solutions didn't answer the original question, but that's partly because I didn't post the original question completely. As I said, this answer doesn't answer the original question completely. If someone knows the complete solution, please let me know.
My solution was a few methods. As they stand, they only work for my case - Cygwin on Windows. (What they do is tell you if the filename argument for the Java application was consistent with being launched from Windows cmd or not.) I plan on posting a more portable group of methods, i.e. other Operating Systems.
I'm sure there are issues. Please point them out to me.
// in main
...
sep = java.io.File.separator; // Thanks #Luke_Lee
if (args != null && args.length != 0)
sep = getSeparatorToUse(args[0]);
...
// member functions
...
private boolean wasLaunchedFromWinCmd(String firstArg)
{
boolean isWindows = System.getProperty("os.name").startsWith("win");
if (! isWindows) return false; // Thanks #Raphael_Moita
else
{
String launchDir = System.getProperty("user.dir");
String rootOfLaunchDir = getRoot(launchDir);
// This will come back with something like "C:\" or "P:\"
String rootOfArgument = getRoot(firstArg);
if (rootOfArgument.equals("/"))
{
String cygwinBase = "/cygdrive/";
char letterOfRoot = rootOfLaunchDir.charAt(0);
// For, e.g., "/Users/me/Desktop/pic_314.jpg"
if (firstArg.startsWith(cygwinBase))
{
int charsToCut = cygwinBase.length();
letterOfRoot = firstArg.substring(charsToCut,
charsToCut + 1);
}//endof: if (firstArg.startsWith(cygwinBase))
System.out.println("The root directory of your argument will be:");
System.out.println(Character.toUpperCase(letterOfRoot) + ":\\");
System.out.println("In Cygwin, that will be:");
System.out.println(cygwinBase +
Character.toLowerCase(letterOfRoot) + "/");
return false;
// Not always correct, e.g. if someone in Cygwin uses
// $ java FileSeparatorExample "C:\pic_137.jpg"
}//endof: if (rootOfArgument.equals("/"))
return true;
}//endof: if/else (! isWindows)
}//endof: private boolean wasLaunchedFromCmd()
private String getRoot(String fileOrDir)
{
File file = new File(fileOrDir).getAbsoluteFile();
File root = file.getParentFile();
while (root.getParentFile() != null)
root = root.getParentFile();
return root.toString();
}//endof: private String getRoot();
private String getSeparatorToUse(String firstArg)
{
if (wasLaunchedFromWinCmd(firstArg))
return "\\"
return "/"
}//endof: private String getSeparatorToUse(String firstArg)
Parts of this solution are due to #Raphael_Moita and #Luke_Lee, but I also need to reference this SO post. This last one helped with my specific situation, where the files are not all hosted on the C:\ drive.
Note
I won't be accepting mine as the correct solution, because it doesn't answer my original question. I hope it might help someone with answering the original question.

directory not created in ubuntu using java [duplicate]

In Java, I'm dynamically creating a set of files and I'd like to change the file permissions on these files on a linux/unix file system. I'd like to be able to execute the Java equivalent of chmod. Is that possible Java 5? If so, how?
I know in Java 6 the File object has setReadable()/setWritable() methods. I also know I could make a system call to do this, but I'd like to avoid that if possible.

Full control over file attributes is available in Java 7, as part of the "new" New IO facility (NIO.2). For example, POSIX permissions can be set on an existing file with setPosixFilePermissions(), or atomically at file creation with methods like createFile() or newByteChannel().
You can create a set of permissions using EnumSet.of(), but the helper method PosixFilePermissions.fromString() will uses a conventional format that will be more readable to many developers. For APIs that accept a FileAttribute, you can wrap the set of permissions with with PosixFilePermissions.asFileAttribute().
Set<PosixFilePermission> ownerWritable = PosixFilePermissions.fromString("rw-r--r--");
FileAttribute<?> permissions = PosixFilePermissions.asFileAttribute(ownerWritable);
Files.createFile(path, permissions);
In earlier versions of Java, using native code of your own, or exec-ing command-line utilities are common approaches.

Prior to Java 6, there is no support of file permission update at Java level. You have to implement your own native method or call Runtime.exec() to execute OS level command such as chmod.
Starting from Java 6, you can useFile.setReadable()/File.setWritable()/File.setExecutable() to set file permissions. But it doesn't simulate the POSIX file system which allows to set permission for different users. File.setXXX() only allows to set permission for owner and everyone else.
Starting from Java 7, POSIX file permission is introduced. You can set file permissions like what you have done on *nix systems. The syntax is :
File file = new File("file4.txt");
file.createNewFile();
Set<PosixFilePermission> perms = new HashSet<>();
perms.add(PosixFilePermission.OWNER_READ);
perms.add(PosixFilePermission.OWNER_WRITE);
Files.setPosixFilePermissions(file.toPath(), perms);
This method can only be used on POSIX file system, this means you cannot call it on Windows system.
For details on file permission management, recommend you to read this post.

In addition to erickson's suggestions, there's also jna, which allows you to call native libraries without using jni. It's shockingly easy to use, and I've used it on a couple of projects with great success.
The only caveat is that it's slower than jni, so if you're doing this to a very large number of files that might be an issue for you.
(Editing to add example)
Here's a complete jna chmod example:
import com.sun.jna.Library;
import com.sun.jna.Native;
public class Main {
private static CLibrary libc = (CLibrary) Native.loadLibrary("c", CLibrary.class);
public static void main(String[] args) {
libc.chmod("/path/to/file", 0755);
}
}
interface CLibrary extends Library {
public int chmod(String path, int mode);
}

For Windows 7 with NIO 2:
public static void main(String[] args) throws IOException {
Path file = Paths.get("c:/touch.txt");
AclFileAttributeView aclAttr = Files.getFileAttributeView(file, AclFileAttributeView.class);
System.out.println(aclAttr.getOwner());
for (AclEntry aclEntry : aclAttr.getAcl()) {
System.out.println(aclEntry);
}
System.out.println();
UserPrincipalLookupService upls = file.getFileSystem().getUserPrincipalLookupService();
UserPrincipal user = upls.lookupPrincipalByName(System.getProperty("user.name"));
AclEntry.Builder builder = AclEntry.newBuilder();
builder.setPermissions( EnumSet.of(AclEntryPermission.READ_DATA, AclEntryPermission.EXECUTE,
AclEntryPermission.READ_ACL, AclEntryPermission.READ_ATTRIBUTES, AclEntryPermission.READ_NAMED_ATTRS,
AclEntryPermission.WRITE_ACL, AclEntryPermission.DELETE
));
builder.setPrincipal(user);
builder.setType(AclEntryType.ALLOW);
aclAttr.setAcl(Collections.singletonList(builder.build()));
}

Just to update this answer unless anyone comes across this later, since JDK 6 you can use
File file = new File('/directory/to/file');
file.setWritable(boolean);
file.setReadable(boolean);
file.setExecutable(boolean);
you can find the documentation on Oracle File(Java Platform SE 7). Bear in mind that these commands only work if the current working user has ownership or write access to that file. I am aware that OP wanted chmod type access for more intricate user configuration. these will set the option across the board for all users.

If you want to set 777 permission to your created file than you can use the following method:
public void setPermission(File file) throws IOException{
Set<PosixFilePermission> perms = new HashSet<>();
perms.add(PosixFilePermission.OWNER_READ);
perms.add(PosixFilePermission.OWNER_WRITE);
perms.add(PosixFilePermission.OWNER_EXECUTE);
perms.add(PosixFilePermission.OTHERS_READ);
perms.add(PosixFilePermission.OTHERS_WRITE);
perms.add(PosixFilePermission.OTHERS_EXECUTE);
perms.add(PosixFilePermission.GROUP_READ);
perms.add(PosixFilePermission.GROUP_WRITE);
perms.add(PosixFilePermission.GROUP_EXECUTE);
Files.setPosixFilePermissions(file.toPath(), perms);
}

You can use the methods of the File class:
http://docs.oracle.com/javase/7/docs/api/java/io/File.html

Apache ant chmod (not very elegant, adding it for completeness) credit shared with #msorsky
Chmod chmod = new Chmod();
chmod.setProject(new Project());
FileSet mySet = new FileSet();
mySet.setDir(new File("/my/path"));
mySet.setIncludes("**");
chmod.addFileset(mySet);
chmod.setPerm("+w");
chmod.setType(new FileDirBoth());
chmod.execute();

for Oralce Java 6:
private static int chmod(String filename, int mode) {
try {
Class<?> fspClass = Class.forName("java.util.prefs.FileSystemPreferences");
Method chmodMethod = fspClass.getDeclaredMethod("chmod", String.class, Integer.TYPE);
chmodMethod.setAccessible(true);
return (Integer)chmodMethod.invoke(null, filename, mode);
} catch (Throwable ex) {
return -1;
}
}
works under solaris/linux.

There is an example class on Oracle Docs which works very much similar to the UNIX chmod. It works with java se 7+ though.

import java.io.File;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.nio.file.attribute.FileAttribute;
import java.nio.file.attribute.PosixFileAttributes;
import java.nio.file.attribute.PosixFilePermission;
import java.nio.file.attribute.PosixFilePermissions;
import java.util.Set;
public class FileAndDirectory1 {
public static void main(String[] args) {
File file = new File("fileTest1.txt");
System.out.println(file.getAbsoluteFile());
try {
//file.createNewFile();
if(!file.exists())
{
//PosixFilePermission is an enum class, PosixFilePermissions is a final class
//create file permissions from string
Set<PosixFilePermission> filePermissions = PosixFilePermissions.fromString("---------"/* "rwxrwxrwx" */);
FileAttribute<?> permissions = PosixFilePermissions.asFileAttribute(filePermissions);
Files.createFile(file.toPath(), permissions);
// printing the permissions associated with the file
System.out.println("Executable: " + file.canExecute());
System.out.println("Readable: " + file.canRead());
System.out.println("Writable: "+ file.canWrite());
file.setExecutable(true);
file.setReadable(true);
file.setWritable(true);
}
else
{
//modify permissions
//get the permission using file attributes
Set<PosixFilePermission> perms = Files.readAttributes(file.toPath(), PosixFileAttributes.class).permissions();
perms.remove(PosixFilePermission.OWNER_WRITE);
perms.add(PosixFilePermission.OWNER_READ);
perms.add(PosixFilePermission.OWNER_EXECUTE);
perms.add(PosixFilePermission.GROUP_WRITE);
perms.add(PosixFilePermission.GROUP_READ);
perms.add(PosixFilePermission.GROUP_EXECUTE);
perms.add(PosixFilePermission.OTHERS_WRITE);
perms.add(PosixFilePermission.OTHERS_READ);
perms.add(PosixFilePermission.OTHERS_EXECUTE);
Files.setPosixFilePermissions(file.toPath(), perms);
System.out.println("Executable: " + file.canExecute());
System.out.println("Readable: " + file.canRead());
System.out.println("Writable: "+ file.canWrite());
file.delete();
}
} catch (IOException e) {
e.printStackTrace();
}
Path path = Paths.get(String.valueOf(file));
System.out.println(path);
}
}

Permission 777 is the same as rwxrwxrwx which you can set as follows:
Files.setPosixFilePermissions(path, PosixFilePermissions.fromString("rwxrwxrwx"))

How can I check if I am running 32bit or 64bit java in C#

I am writing my first C# program and I want to check using C# code if I am running a 32 or 64 bit version of java ?
I tried this but when I add this code to my class I am not able to debug it
RegistryKey rk = Registry.LocalMachine;
RegistryKey subKey = rk.OpenSubKey("SOFTWARE\\JavaSoft\\Java Runtime Environment");
string currentVerion = subKey.GetValue("CurrentVersion").ToString();
How can I do it ?
Thanks

It isn't clear how you are going to identify which java.exe you are using - a single machine can have many installed. You may have a specific path, or you may need to either use the JAVA_HOME environment variable, or search PATH, or do a combination of both and give priority to one or the other depending on your requirements.
Once you've got your path to java.exe you can use the technique from Kris Stanton on MSDN (which I will repeat here, but is currently linked at MSDN > "Exploring pe file headers using managed code"):
public enum MachineType
{
Native = 0, I586 = 0x014c, Itanium = 0x0200, x64 = 0x8664
}
public static MachineType GetMachineType(string fileName)
{
// dos header is 64 bytes
// PE header address is 4 bytes
const int PE_PTR_OFFSET = 60;
const int MACHINE_OFFSET = 4;
byte[] data = new byte[4096];
using (Stream stm = new FileStream(fileName, FileMode.Open, FileAccess.Read))
{
stm.Read(data, 0, 4096);
}
int PE_HDR_ADDR = BitConverter.ToInt32(data, PE_PTR_OFFSET);
int machineUint = BitConverter.ToUInt16(data, PE_HDR_ADDR + MACHINE_OFFSET);
return (MachineType)machineUint;
}
To find java.exe on the %PATH% variable, you can call FindOnPath("java.exe"):
public static String FindOnPath(string exeName)
{
foreach (string test in (Environment.GetEnvironmentVariable("PATH") ?? "").Split(';'))
{
string path = test.Trim();
if (!String.IsNullOrEmpty(path) && File.Exists(path = Path.Combine(path, exeName)))
return Path.GetFullPath(path);
}
return null;
}
On my machine, the following code
static void Main(string[] args)
{
String path = FindOnPath("java.exe");
Console.WriteLine(path);
Console.WriteLine(GetMachineType(path));
}
writes the following output:
C:\ProgramData\Oracle\Java\javapath\java.exe
x64

You can do it through the registry. I knocked together a quick example for you:
private string GetJavaInstallationPath()
{
string environmentPath = Environment.GetEnvironmentVariable("JAVA_HOME");
if (!string.IsNullOrEmpty(environmentPath))
{
return environmentPath;
}
string javaKey = "SOFTWARE\\JavaSoft\\Java Runtime Environment\\";
using (Microsoft.Win32.RegistryKey rk = Microsoft.Win32.Registry.LocalMachine.OpenSubKey(javaKey))
{
string currentVersion = rk.GetValue("CurrentVersion").ToString();
using (Microsoft.Win32.RegistryKey key = rk.OpenSubKey(currentVersion))
{
return key.GetValue("JavaHome").ToString();
}
}
}
Then to use it, just do the following:
string installPath = GetJavaInstallationPath();
string filePath = System.IO.Path.Combine(installPath, "bin\\Java.exe");
if (System.IO.File.Exists(filePath))
{
// We have a winner
}

I`m use this code:
public static bool CheckJavaInstallation()
{
try
{
//ProcessStartInfo procStartInfo = new ProcessStartInfo("java", " -version"); // Check that any Java installed
//ProcessStartInfo procStartInfo = new ProcessStartInfo("java", "-d32 -version"); // Check that 32 bit Java installed
ProcessStartInfo procStartInfo = new ProcessStartInfo("java", "-d64 -version"); // Check that 64 bit Java installed
procStartInfo.RedirectStandardOutput = true;
procStartInfo.RedirectStandardError = true;
procStartInfo.UseShellExecute = false;
procStartInfo.CreateNoWindow = true;
Process proc = new Process {StartInfo = procStartInfo};
proc.Start();
proc.BeginOutputReadLine();
proc.BeginErrorReadLine();
proc.WaitForExit();
return proc.ExitCode == 0;
}
catch (Exception ex)
{
return false;
}
}

Determine whether a file is a junction (in Windows) or not?

I've been searching around trying to find a way to determine if a file is a junction or not, and have not found any satisfactory answers.
First thing I tried was:
Files.isSymbolicLink(aPath)
It detects only symbolic links not the files referred to as junctions in Windows.
Also tried the solution proposed here (using JNA library):
Stackoverflow question (3249117)
, but it never returned true on any of the files I know to be junctions.
The only way I've found to determine which files are junctions is the following command run in windows command prompt:
DIR /S /A:L
On my computer it returns 66 folders, wheras Files.isSymbolicLink(aPath) returned only 2.
So I suppose I could find a way to utilize this, but I don't think it would be very effiecient when traversing a filetree.
Is there any way to do this using the standard java library, or alternativly JNA?

There can be a way to do it without JNA, if you have the right java, such as Oracle jdk 8. It's dodgy, it can cease to work, but....
You can get BasicFileAttributes interface related to the link:
BasicFileAttributes attr = Files.readAttributes(path, BasicFileAttributes.class, LinkOption.NOFOLLOW_LINKS);
It can happen that this interface implementation is a class
sun.nio.fs.WindowsFileAttributes. And this class has a method isReparsePoint, which returns true for both junction points and symbolic links. So you can try to use reflection and call the method:
boolean isReparsePoint = false;
if (DosFileAttributes.class.isInstance(attr))
try {
Method m = attr.getClass().getDeclaredMethod("isReparsePoint");
m.setAccessible(true);
isReparsePoint = (boolean) m.invoke(attr);
} catch (Exception e) {
// just gave it a try
}
Now you only can discover whether it really is symbolic link: Files.isSymbolicLink(path)
If its not, but it is reparse point, then that's junction.

If you can write native code in JNA, you can directly call the Win32 API GetFileAttributes() function and check for the FILE_ATTRIBUTE_REPARSE_POINT flag (junctions are implemented as reparse points).
Update: To differentiate between different types of reparse points, you have to retreive the ReparseTag of the actual reparse point. For a junction point, it will be set to IO_REPARSE_TAG_MOUNT_POINT (0xA0000003).
There are two ways to retreive the ReparseTag:
Use DeviceIoControl() with the FSCTL_GET_REPARSE_POINT control code to obtain an REPARSE_DATA_BUFFER struct, which as a ReparseTag field. You can see an example of an IsDirectoryJunction() implementation using this technique in the following article:
NTFS Hard Links, Directory Junctions, and Windows Shortcuts
Use FindFirstFile() to obtain a WIN32_FIND_DATA struct. If the path has the FILE_ATTRIBUTE_REPARSE_POINT attribute, the dwReserved0 field will contain the ReparseTag.

With J2SE 1.7 use Java NIO
/**
* returns true if the Path is a Windows Junction
*/
private static boolean isJunction(Path p) {
boolean isJunction = false;
try {
isJunction = (p.compareTo(p.toRealPath()) != 0);
} catch (IOException e) {
e.printStackTrace(); // TODO: handleMeProperly
}
return isJunction;
}

While on Windows a junction's attributes have isSymbolicLink() == false, they have isOther() == true. So you could do something like:
boolean isWindows = System.getProperty("os.name").toLowerCase().contains("windows")
BasicFileAttributes attrs = Files.readAttributes(aPath, BasicFileAttributes.class, LinkOption.NOFOLLOW_LINKS);
boolean isJunction = isWindows && attrs.isDirectory() && attrs.isOther();

Black-Box Solution:
aPath.toRealPath() resolves junctions and symbolic links, so the result will deviate from aPath.
In addition BasicFileAttributes.isSymbolicLink() delivers false for junctions for non-documented reason:
E.g. Path.toRealPath(LinkOption.NOFOLLOW_LINKS) well treats a junction as link an does not resolve it!!
So by non-identity of toRealPath() and BasicFileAttributes.isSymbolicLink() you may identify a junction.

You can discover the link type with PowerShell with the command
(Get-Item -Path fileName -Force).LinkType
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.nio.file.Path;
import java.util.Arrays;
import java.util.List;
import java.util.Optional;
class WindowsFileLinkUtils {
public enum WindowsLinkType {
JUNCTION("Junction"),
HARD_LINK("HardLink"),
SYMBOLIC_LINK("SymbolicLink");
private final String key;
WindowsLinkType(String key) {
this.key = key;
}
public String getKey() {
return key;
}
}
private static final String CREATE_JUNCTION_COMMAND = "(Get-Item -Path %s -Force).LinkType";
public static Optional<WindowsLinkType> getLinkType(Path path) throws IOException, InterruptedException {
ProcessBuilder processBuilder = createIsJunctionProcessBuilder(path);
Process process = processBuilder.start();
process.waitFor();
try (BufferedReader inStreamReader = new BufferedReader(new InputStreamReader(process.getInputStream()))) {
String output = inStreamReader.readLine();
return Arrays.stream(WindowsLinkType.values()).filter(windowsLinkType -> windowsLinkType.getKey().equals(output)).findFirst();
}
}
private static ProcessBuilder createIsJunctionProcessBuilder(Path target) {
ProcessBuilder processBuilder = new ProcessBuilder();
List<String> arguments = processBuilder.command();
arguments.add("powershell.exe");
arguments.add(String.format(CREATE_JUNCTION_COMMAND, target.toString()));
return processBuilder;
}
private WindowsFileLinkUtils() {
}
}

Java: load a library that depends on other libs

I want to load my own native libraries in my java application. Those native libraries depend upon third-party libraries (which may or may not be present when my application is installed on the client computer).
Inside my java application, I ask the user to specify the location of dependent libs. Once I have this information, I am using it to update the "LD_LIBRARY_PATH" environment variable using JNI code. The following is the code snippet that I am using to change the "LD_LIBRARY_PATH" environment variable.
Java code
public static final int setEnv(String key, String value) {
if (key == null) {
throw new NullPointerException("key cannot be null");
}
if (value == null) {
throw new NullPointerException("value cannot be null");
}
return nativeSetEnv(key, value);
}
public static final native int nativeSetEnv(String key, String value);
Jni code (C)
JNIEXPORT jint JNICALL Java_Test_nativeSetEnv(JNIEnv *env, jclass cls, jstring key, jstring value) {
const char *nativeKey = NULL;
const char *nativeValue = NULL;
nativeKey = (*env)->GetStringUTFChars(env, key, NULL);
nativeValue = (*env)->GetStringUTFChars(env, value, NULL);
int result = setenv(nativeKey, nativeValue, 1);
return (jint) result;
}
I also have corresponding native methods to fetch the environment variable.
I can successfully update the LD_LIBRARY_PATH (this assertion is based on the output of C routine getenv().
I am still not able to load my native library. The dependent third-party libraries are still not detected.
Any help/pointers are appreciated. I am using Linux 64 bit.
Edit:
I wrote a SSCE (in C) to test if dynamic loader is working. Here is the SSCE
#include
#include
#include
#include
int main(int argc, const char* const argv[]) {
const char* const dependentLibPath = "...:";
const char* const sharedLibrary = "...";
char *newLibPath = NULL;
char *originalLibPath = NULL;
int l1, l2, result;
void* handle = NULL;
originalLibPath = getenv("LD_LIBRARY_PATH");
fprintf(stdout,"\nOriginal library path =%s\n",originalLibPath);
l1 = strlen(originalLibPath);
l2 = strlen(dependentLibPath);
newLibPath = (char *)malloc((l1+l2)*sizeof(char));
strcpy(newLibPath,dependentLibPath);
strcat(newLibPath,originalLibPath);
fprintf(stdout,"\nNew library path =%s\n",newLibPath);
result = setenv("LD_LIBRARY_PATH", newLibPath, 1);
if(result!=0) {
fprintf(stderr,"\nEnvironment could not be updated\n");
exit(1);
}
newLibPath = getenv("LD_LIBRARY_PATH");
fprintf(stdout,"\nNew library path from the env =%s\n",newLibPath);
handle = dlopen(sharedLibrary, RTLD_NOW);
if(handle==NULL) {
fprintf(stderr,"\nCould not load the shared library: %s\n",dlerror());
exit(1);
}
fprintf(stdout,"\n The shared library was successfully loaded.\n");
result = dlclose(handle);
if(result!=0) {
fprintf(stderr,"\nCould not unload the shared library: %s\n",dlerror());
exit(1);
}
return 0;
}
The C code also does not work. Apparently, the dynamic loader is not rereading the LD_LIBRARY_PATH environment variable. I need to figure out how to force the dynamic loader to re-read the LD_LIBRARY_PATH environment variable.

See the accepted answer here:
Changing LD_LIBRARY_PATH at runtime for ctypes
In other words, what you're trying to do isn't possible. You'll need to launch a new process with an updated LD_LIBRARY_PATH (e.g., use ProcessBuilder and update environment() to concatenate the necessary directory)

This is a hack used to manipulate JVM's library path programmatically. NOTE: it relies on internals of ClassLoader implementation so it might not work on all JVMs/versions.
String currentPath = System.getProperty("java.library.path");
System.setProperty( "java.library.path", currentPath + ":/path/to/my/libs" );
// this forces JVM to reload "java.library.path" property
Field fieldSysPath = ClassLoader.class.getDeclaredField( "sys_paths" );
fieldSysPath.setAccessible( true );
fieldSysPath.set( null, null );
This code uses UNIX-style file path separators ('/') and library path separator (':'). For cross-platform way of doing this use System Properties to get system-specific separators: http://download.oracle.com/javase/tutorial/essential/environment/sysprop.html

I have successfully implemented something similar for CollabNet Subversion Edge, which depends on the SIGAR libraries across ALL Operating Systems (we support Windows/Linux/Sparc both 32 bits and 64 bits)...
Subversion Edge is a web application that helps one managing Subversion repositories through a web console and uses SIGAR to the SIGAR libraries helps us provide users data values directly from the OS... You need to update the value of the property "java.library.path" at runtime. (https://ctf.open.collab.net/integration/viewvc/viewvc.cgi/trunk/console/grails-app/services/com/collabnet/svnedge/console/OperatingSystemService.groovy?revision=1890&root=svnedge&system=exsy1005&view=markup Note that the URL is a Groovy code, but I have modified it to a Java here)...
The following example is the implementation in URL above... (On Windows, your user will be required to restart the machine if he/she has downloaded the libraries after or downloaded them using your application)... The "java.library.path" will update the user's path "usr_paths" instead of System path "sys_paths" (permissions exception might be raised depending on the OS when using the latter).
133/**
134 * Updates the java.library.path at run-time.
135 * #param libraryDirPath
136 */
137 public void addDirToJavaLibraryPathAtRuntime(String libraryDirPath)
138 throws Exception {
139 try {
140 Field field = ClassLoader.class.getDeclaredField("usr_paths");
141 field.setAccessible(true);
142 String[] paths = (String[])field.get(null);
143 for (int i = 0; i < paths.length; i++) {
144 if (libraryDirPath.equals(paths[i])) {
145 return;
146 }
147 }
148 String[] tmp = new String[paths.length+1];
149 System.arraycopy(paths,0,tmp,0,paths.length);
150 tmp[paths.length] = libraryDirPath;
151 field.set(null,tmp);
152 String javaLib = "java.library.path";
153 System.setProperty(javaLib, System.getProperty(javaLib) +
154 File.pathSeparator + libraryDirPath);
155
156 } catch (IllegalAccessException e) {
157 throw new IOException("Failed to get permissions to set " +
158 "library path to " + libraryDirPath);
159 } catch (NoSuchFieldException e) {
160 throw new IOException("Failed to get field handle to set " +
161 "library path to " + libraryDirPath);
162 }
163 }
The Bootstrap services (Groovy on Grails application) class of the console runs a service and executes it with the full path to the library directory... UNiX-based servers do not need to restart the server to get the libraries, but Windows boxes do need a server restart after the installation. In your case, you would be calling this as follows:
String appHomePath = "/YOUR/PATH/HERE/TO/YOUR/LIBRARY/DIRECTORY";
String yourLib = new File(appHomePath, "SUBDIRECTORY/").getCanonicalPath();
124 try {
125 addDirToJavaLibraryPathAtRuntime(yourLib);
126 } catch (Exception e) {
127 log.error("Error adding the MY Libraries at " + yourLib + " " +
128 "java.library.path: " + e.message);
129 }
For each OS you ship your application, just make sure to provide a matching version of the libraries for the specific platform (32bit-Linux, 64bit-Windows, etc...).