Java Puzzlers By Joshua Bloch, Neal Gafter

Just now i finished solving puzzles from Java Puzzlers book by Joshua Bloch, Neal Gafter.

Oh!! What a book and my comment on the book is same as Guy Steele "I laughed, I cried, I threw up (my hands in admiration)."

Please go fast and get a copy of the book if not till now.

Ok i wanted to share few puzzles from the book with my readers.

1)
This program has two declarations of the same name in the same scope and no obvious way to choose between them. Does the program print Black? Does it print White? Is it even legal?

public class ShadesOfGray {
    public static void main(String[] args){
        System.out.println(X.Y.Z);
    }
}

class X {
    static class Y {
        static String Z = "Black";
    } 

    static C Y = new C();
}

class C {
    String Z = "White";
}

Solution:
If you tried it, you found that it is legal and prints White.
When a variable and a type have the same name and both are in scope, the variable name takes precedence [JLS 6.5.2]. Similarly, variable and type names can obscure package names.In summary, obey the standard naming conventions to avoid conflicts between different namespaces

2) Suppose that you can't modify classes X and C in the previous puzzle. Can you write a class whose main method reads the value of the field Z in class X.Y and prints it? Do not use reflection.

At first, this puzzle may appear impossible.In fact, it is possible to refer to an obscured type name. The trick is to use the name in a syntactic context where a type is allowed but a variable is not. The following program solves the puzzle by using this technique and prints Black as expected:

public class FadeToBlack {
    public static void main(String[] args){
     System.out.println(((X.Y)null).Z);
    }
}

3) This program involves the interaction of two classes in different packages. The main method is in class hack.TypeIt. What does the program print?

package click;
public class CodeTalk {
    public void doIt() {
        printMessage();
    }

    void printMessage() {
        System.out.println("Click");
    }
}

package hack;
import click.CodeTalk;

public class TypeIt {
    private static class ClickIt extends CodeTalk {
        void printMessage() {
            System.out.println("Hack");
        }
    }

    public static void main(String[] args) {
        ClickIt clickit = new ClickIt();
        clickit.doIt();
    }
}

Solution: if you run the program, it prints Click. How can this be? A package-private method cannot be directly overridden by a method in a different package [JLS 8.4.8.1].The two printMessage methods in this program are unrelated; they merely have the same name. When the program calls printMessage from within the package hack, the package-private method hack.TypeIt.ClickIt.printMessage is run. This method prints Click, which explains the observed behavior you want the printMessage method in hack.TypeIt.ClickIt to override the method in click.CodeTalk, you must add the protected or public modifier to the method declaration in click.CodeTalk

4) This program is incomplete. It lacks a declaration for Enigma, a class that extends java.lang.Object. Provide a declaration for Enigma that makes the program print false:

public class Conundrum {

    public static void main(String[] args) {

        Enigma e = new Enigma();

        System.out.println(e.equals(e));

    }

}

Oh, and one more thing: You must not override equals.


Solution:

At first glance, this may seem impossible. The Object.equals method tests for object identity, and the object passed to equals by Enigma is certainly the same as itself. If you can't override Object.equals, the main method must print TRue, right?

Not so fast, cowboy. Although the puzzle forbids you to override Object.equals, you are permitted to overload it, which leads to the following solution:

final class Enigma {

    // Don't do this!

    public boolean equals(Enigma other) {

        return false;

    }

}

Although this solves the puzzle, it is a very bad thing to do. It violates the advice of Puzzle 58: If two overloadings of the same method can be applied to some parameters, they should have identical behavior. In this case, e.equals(e) and e.equals((Object)e) return different results. The potential for confusion is obvious

There is, however, a solution that doesn't violate this advice:

final class Enigma {

    public Enigma() {

        System.out.println(false);

        System.exit(0);

    }

}

Hope you enjoy reading all puzzles.

About the Authors:

Joshua Bloch
Joshua is Chief Java Architect at Google Inc. Previously, he was a Distinguished Engineer at Sun Microsystems Inc., where he was an architect in the Core Java Platform Group. He designed, implemented, and maintained many parts of the Java platform, including the award-winning Java Collections Framework and many J2SE 5.0 language features. Previously he was a Senior Systems Designer at Transarc Corporation, where he designed and implemented many parts of the Encina distributed transaction processing system.

In addition to Java Puzzlers, Joshua wrote the Jolt award-winning bestseller Effective Java Programming Language Guide and the Collections chapter in The Java Tutorial.

He holds a B.S. from Columbia University and a Ph.D. from Carnegie-Mellon University. His Ph.D. thesis on the replication of abstract data objects was nominated for the ACM Distinguished Dissertation Award.

Neal Gafter
Neal is a Staff Software Engineer and Java Evangelist at Google. He was previously a Senior Staff Engineer at Sun Microsystems, where he led the development of the Java compiler and implemented the Java language features in releases 1.4 through 5.0. Neal was a member of the C++ Standards Committee and led the development of C and C++ compilers at Sun Microsystems, Microtec Research, and Texas Instruments. He holds a PhD in computer science from the University of Rochester