Saturday, September 25, 2010

Windows has sym links!

Here is a little known (at least to me) fact about Windows Vista and Windows 7: they support symbolic links!

The command you need to use for this is mklink, and here is the syntax:

Creates a symbolic link.

MKLINK [[/D] | [/H] | [/J]] Link Target

/D Creates a directory symbolic link. Default is a file symbolic link.
/H Creates a hard link instead of a symbolic link.
/J Creates a Directory Junction.
Link specifies the new symbolic link name.
Target specifies the path (relative or absolute) that the new link refers to.

Here is an example of a soft link for a directory:

>mklink /d linkdir1 dir1
symbolic link created for linkdir1 <<===>> dir1

which comes up clearly noted in a directory listing from the command prompt

09/25/2010 12:59 AM <dir> dir1
09/25/2010 12:59 AM <symlinkd> linkdir1 [dir1]

as well as in the Windows explorer, by means of an icon overlay.

You need admin privileges to create such a link, unless you edit the Local Security Policies and add the Create Symbolic Link privilege.


This is a junction for a directory:

>mklink /j junctiondir1 dir1
Junction created for junctiondir1 <<===>> dir1

Again, clearly noted from the command prompt:

09/25/2010 12:59 AM <dir> dir1
09/25/2010 01:01 AM <junction> junctiondir1 [C:\...\dir1]

and identified in Windows graphical interface by the same icon overlay as the soft link case

A junction is a directory hard link.

Beware to delete directory links with rmdir, as del will delete the contents instead of the link! Also, deleting the original directory breaks both the symlink and the junction!

Here is a soft link for a file:

>mklink linkfile.txt file1.txt
symbolic link created for linkfile.txt <<===>> file1.txt

Showing up in the command prompt as:

09/25/2010 01:22 AM <symlink> linkfile.txt [file1.txt]

and with the same icon overlay as for directories in Windows explorer


And this is a hard link for a file:

>mklink /h hardlinkfile.txt file1.txt
Hardlink created for hardlinkfile.txt <<===>> file1.txt

Notice how you cannot tell from the command prompt:

09/25/2010 01:23 AM 32 hardlinkfile.txt

or from the Windows shell, since there is no icon overlay

Now, deleting the original file will break the soft link but not affect the hard link

So, recapping:

mklink name target
  • creates a file soft link
  • appears in the cmd prompt as <symlink>
  • has an icon overlay (a little arrow as in shortcuts) in the Windows shell

mklink /h name target
  • creates a file hard link
  • appears in the cmd prompt as any other file (works as full-fledged file and remains if you delete the original)
  • has no icon overlay (behaves like any other file)

mklink /d name target
  • creates a directory soft link
  • appears in the cmd prompt as <symlinkd>
  • has an icon overlay (a little arrow as in shortcuts) in the Windows shell

mklink /j name target
  • creates a directory hard link (although deleting the original location actually renders the link unsable)
  • appears in the cmd prompt as <junction>
  • has an icon overlay (a little arrow as in shortcuts) in the Windows shell


One last note (I tried this in Windows Vista): if you move the links (not the original files/directories) to another location, junctions and hard links keep working, while directory and file soft links break.

Enjoy - I know I like this!

Wednesday, September 15, 2010

Double dispatch to solve compile method resolution issues in Java

I usually don't chain posts, but it was going to be very long so... this post is a continuation of the previous one.

Here's how to use double dispatch for the compile time method resolution case. Note that the doubleDispatch method must be defined both for Mammal and for Dog.


public class OverloadingExamples {

public static class Mammal {
public void sayHello() {
System.out.println("Hi, I'm a mammal!");
}

public void doubleDispatch(OverloadingExamples example) {
example.makeSayHello(this);
}
}

public static class Dog extends Mammal {
@Override
public void sayHello() {
System.out.println("Hi, I'm a mammal - in fact I'm a dog!");
}

@Override
public void doubleDispatch(OverloadingExamples example) {
example.makeSayHello(this);
}
}

private Dog getADog() {
return new Dog();
}

public void runExample() {

Mammal aMammal = getADog();

System.out.println("Run time method resolution");
aMammal.sayHello();

System.out.println();

System.out.println("Double dispatch resolutions");
aMammal.doubleDispatch(this);

Dog aDog = (Dog) aMammal;
aDog.doubleDispatch(this);
}

public void makeSayHello(Mammal aMammal) {
System.out.println("Compile time method resolution for a MAMMAL");
System.out.print("Corresponding run time method resolution: ");
aMammal.sayHello();
}

public void makeSayHello(Dog aDog) {
System.out.println("Compile time method resolution for a DOG");
System.out.print("Corresponding run time method resolution: ");
aDog.sayHello();
}

public static void main(String args[]) {
new OverloadingExamples().runExample();
}
}


Now here's the output:

Run time method resolution
Hi, I'm a mammal - in fact I'm a dog!

Double dispatch resolutions
Compile time method resolution for a DOG
Corresponding run time method resolution: Hi, I'm a mammal - in fact I'm a dog!
Compile time method resolution for a DOG
Corresponding run time method resolution: Hi, I'm a mammal - in fact I'm a dog!

And the makeSayHello(Mammal) implementation was not used.

Run time and compile time method resolution in Java

This post is thanks to a colleague at work.

Suppose you have a class Dog and a class Mammal it inherits from. Both have a method sayHello().

public static class Mammal {
public void sayHello() {
System.out.println("Hi, I'm a mammal!");
}
}

public static class Dog extends Mammal {
@Override
public void sayHello() {
System.out.println("Hi, I'm a mammal - in fact I'm a dog!");
}
}

If you were to call sayHello() on an instance of Dog which is declared (to the compiler) as a Mammal:

private Dog getADog() {
return new Dog();
}

public void runExample() {

Mammal aMammal = getADog();

System.out.println("Run time method resolution");
aMammal.sayHello();
.......

This would print:

Run time method resolution
Hi, I'm a mammal - in fact I'm a dog!

No surprises there, just a virtual method.

But now, suppose you have:

public void makeSayHello(Mammal aMammal) {
System.out.println("Compile time method resolution for a MAMMAL");
System.out.print("Corresponding run time method resolution: ");
aMammal.sayHello();
}

public void makeSayHello(Dog aDog) {
System.out.println("Compile time method resolution for a DOG");
System.out.print("Corresponding run time method resolution: ");
aDog.sayHello();
}

and in the example you call:

public void runExample() {

Mammal aMammal = getADog();

System.out.println("Run time method resolution");
aMammal.sayHello();

System.out.println();

System.out.println("Compile time method resolutions");
makeSayHello(aMammal);

Dog aDog = (Dog) aMammal;
makeSayHello(aDog);
}

aMammal is always the same object - a dog. In the second occurence, it's explicity cast as such.

Will both calls to makeSayHello use the makeSayHello(Dog aDog) method?

No - the first call will use makeSayHello(Mammal aMammal). Why? Because when it comes to method parameters, the resolution of overloaded methods is done at compile time. Otherwise stated, when overriding methods the 'closest' version will we used, by virtue of virtuality (pardon the repetition). When overloading methods, the version called will be the one that matches the compile time declaration of the parameter.

Note that the calls to aMammal.sayHello() and aDog.sayHello() in the respective makeSayHello() methods will call the Dog implementation (here we are using method overriding again).

The complete example follows:


public class OverloadingExamples {

public static class Mammal {
public void sayHello() {
System.out.println("Hi, I'm a mammal!");
}
}

public static class Dog extends Mammal {
@Override
public void sayHello() {
System.out.println("Hi, I'm a mammal - in fact I'm a dog!");
}
}

private Dog getADog() {
return new Dog();
}

public void runExample() {

Mammal aMammal = getADog();

System.out.println("Run time method resolution");
aMammal.sayHello();

System.out.println();

System.out.println("Compile time method resolutions");
makeSayHello(aMammal);

Dog aDog = (Dog) aMammal;
makeSayHello(aDog);
}

public void makeSayHello(Mammal aMammal) {
System.out.println("Compile time method resolution for a MAMMAL");
System.out.print("Corresponding run time method resolution: ");
aMammal.sayHello();
}

public void makeSayHello(Dog aDog) {
System.out.println("Compile time method resolution for a DOG");
System.out.print("Corresponding run time method resolution: ");
aDog.sayHello();
}

public static void main(String args[]) {
new OverloadingExamples().runExample();
}
}

And here's the output:

Run time method resolution
Hi, I'm a mammal - in fact I'm a dog!

Compile time method resolutions
Compile time method resolution for a MAMMAL
Corresponding run time method resolution: Hi, I'm a mammal - in fact I'm a dog!
Compile time method resolution for a DOG
Corresponding run time method resolution: Hi, I'm a mammal - in fact I'm a dog!