Windows 10 table control: area right beside column header is black

SmartGit, SmartSVN and SmartSynchronize show a black area right beside the last column in the header area.

Screenshot

It is following bug in SWT

bugs.eclipse.org/bugs/show_bug.cgi?id=474096

and we don’t know of a work-around for now. We would like to encourage you to vote for this bug at bugs.eclipse.org, so it will get the necessary priority.

Update Aug-18-2015
Though the SWT team has fixed it, Microsoft also released a fix for Windows 10 which solved this problem.

SmartGit, SmartSVN, SmartSynchronize hang on OS X 10.11 beta 3

SmartGit, SmartSVN, SmartSynchronize and a lot of other Java-based (GUI) applications, e.g. Eclipse, hang on OS X 10.11 beta 3 / public beta 1 (El Capitan). They worked on previous OS X 10.11 beta versions.

It is discussed in following thread forums.developer.apple.com/thread/8776.

We will see whether Apple fixes it in a new beta version.

Update on July 27th 2015
The problem has been fixed by Apple with the release of OS X 10.11 public beta 2.

file.exist() and broken symlinks

Today I’ve found a problem with file.exists() for broken symlinks on OS X. Here is a simplified code example:

for (File file: files) {
  if (!file.exists()) {
    continue;
  }

  if (file.isDirectory()) {
    deleteRecursively(file);
  }
  else {
    file.delete();
  }
}

This looks quiet fine at the first sight, but this may cause problems if the file is a broken symlink, because file.exists() returns false for a broken symlink. Hence, in the above example code, the broken symlink will not be deleted.

Launching Terminal (cmd.exe) from Java

Until now SmartGit used following command for its default Open in Terminal external tool:

cmd.exe /k start /d <path>

This did not work for paths like C:\foo, bar+=hello & world though SmartGit had logic to escape the path in this case when launching cmd.exe. Also, the Task Manager showed two running cmd.exe processes, one remaining after the window has been closed. Changing the command to

cmd.exe /c start pushd <path>

resolves both problems and the path-escaping logic also is not necessary anymore.