Saturday, April 18, 2015

Java Concurrency Problem: A Producer which produces N work items and waits for them to be over.

“With great power often comes great confusion.” ― Dan Allen, Seam in Action

Many times we encounter concurrency problems in Java where existing constructs need to be tweaked. Recently I wrote about one such problem where we wanted to accumulate results of multiple threads and these threads could write or update values randomly.

This time I am going to write about a problem where we will have one producer which will produce an N number of items (of course N is not known in advance) and then producer needs to wait for all those N items to be over. Before we move further I would like to stress again that what I am going to present here is oversimplified version of actual problem. I am not going to write complete code rather only those pieces that would make sense in context of this post.

Using ExecutorCompletionService
If you are not familiar then you need to have a look on this post which explains how ExecutorCompletionService differentiates from ExecutorService. My worker will doing some work and that's all.
public class WorkerThread implements Runnable {
    @Override
    public void run() {
        try {
            Thread.currentThread().sleep(1000);  // do some work
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

At first it seems that we can use this to submit jobs and get list of futures, and then later we can get results out of it. When we will be retrieving the results using take() producer will obviously block.
public class WorkProducerUsingECS implements Runnable{
    private final CompletionService service;
    private final List<Future<Integer>> listOfFutures;

    public WorkProducerUsingECS() {
        this.listOfFutures = new ArrayList<>();
        service = new ExecutorCompletionService(Executors.newFixedThreadPool(5));
    }

    @Override
    public void run() {
        produceRandomWorkers();
    }

    private void produceRandomWorkers() {
        Random random = new Random();
        int numberOfWorkers = random.nextInt(20) + 1;
        System.out.println("Workers count: " + numberOfWorkers);
        for (int i=0; i<numberOfWorkers; i++){
             listOfFutures.add(service.submit(new WorkerThread(),1));
        }
    }

    private void getResultAfterWorkIsOver() throws InterruptedException, ExecutionException {
        for(int i=0; i<listOfFutures.size(); i++) {
            Integer result = (Integer) service.take().get();
            System.out.println("Result: "  + result);
        }
    }
}

This can be called using the following code:
public static void main(String[] args) {
   WorkProducerUsingECS producer =  new WorkProducerUsingECS();
   Thread thread = new Thread(producer);
   thread.start();
}

Now the problem is once all the workers are done how can we signal the producer so that it can call getResultAfterWorkIsOver method.

Using CountDownLatch (CDL)
Using latch seems a good option but the problem is we don't know the actual number of worker threads in advance. If it were available we could have simply created a CDL and have producer thread wait (using await method) until all work was complete.

Lets give it a try. We will create a wrapper class WorkerTask on top of class which will take Runnable (to be executed) and an atomic reference to CDL as constructor parameter. An AtomicReference can be updated atomically.
public class WorkerTask implements Runnable {
    private final Runnable runnable;
    private AtomicReference<CountDownLatch> latchAtomicReference;

    public WorkerTask(Runnable runnable, AtomicReference<CountDownLatch> latchAtomicReference) {
        this.runnable = runnable;
        this.latchAtomicReference = latchAtomicReference;
    }

    @Override
    public void run(){
        runnable.run();
        while (latchAtomicReference.get() == null) {
            try {
                Thread.currentThread().sleep(1000L);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        latchAtomicReference.get().countDown();
    }
}

In case any worker-thread is over by the time CDL is not set, it will sleep for some time and again check whether it is set or not. If it is set then it will invoke countdown on it. The AtomicReference is used because this can be updated atomically and will not create unintended problems in multi-threaded code.

Another thing to note is I have called run() and not start() on the Runnable passed in constructor as I do not want to spawn a new thread. You can read more here and here. This can be used with producer as:
public class WorkProducerUsingCDL implements Runnable{
    private final AtomicReference<CountDownLatch> latchAtomicReference;

    public WorkProducerUsingCDL() {
        latchAtomicReference = new AtomicReference<>();
    }

    @Override
    public void run() {
        produceRandomWorkers();
    }

    private void produceRandomWorkers() {
        Random random = new Random();
        int numberOfWorkers = random.nextInt(20) + 1;
        System.out.println("Workers count: " + numberOfWorkers);
        for (int i=0; i<numberOfWorkers; i++){
            try {
                createWorkerTask().start();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }

        // Add some delay to simulate some processing
        try {
            Thread.currentThread().sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        //By now all workers have been added. Some of them may be over and some may be processing.
        latchAtomicReference.set(new CountDownLatch(numberOfWorkers));

        // Now producer will wait for latch to be over.
        try {
            latchAtomicReference.get().await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        // Now all workers are definitely over.
        try {
            processAfterWorkIsOver();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (ExecutionException e) {
            e.printStackTrace();
        }
    }

    private Thread createWorkerTask() {
        WorkerTask workerTask = new WorkerTask(new WorkerThread(), latchAtomicReference);
        Thread thread = new Thread(workerTask);
        return  thread;
    }

    private void processAfterWorkIsOver() throws InterruptedException, ExecutionException {
        System.out.println("Work is over by all workers.");
    }

}

And we can verify this code as:
public static void main(String[] args) {
    WorkProducerUsingCDL producerUsingCDL = new WorkProducerUsingCDL();
    Thread thread = new Thread(producerUsingCDL);
    thread.start();
}

One thing to observe in this code is that the number of threads is unknown to us and it is possible that some of the threads have already near to completion by the time we create a CDL and set it in the AtomicReference of CDL. I have not used ExecutorService here knowingly in this example because that would have returned Future and when we invoke get on it, it will block the producer. Here also producer will be blocked but by the await method which is called on CDL in the AtomicReference.

This code should work and in my opinion not a neat version. One more point which is still not discussed is: the process is cyclic. It means every time a cycle starts producer will produce unknown number of threads and will wait for them to be completed. It seems we can also make use of CyclicBarrier to solve this problem. Think for a moment before going further. Can we solve it using CyclicBarrier?

Using Phaser
As we do not have Flexible CDL, there is one construct that will fit the problem and that is Phaser. To know about why and how to use Phaser check this post. We need to pass the phaser reference to worker as:
public class WorkerThread implements Runnable {
    private final Phaser phaser;

    public WorkerThread(Phaser phaser) {
        this.phaser = phaser;
    }

    @Override
    public void run() {
        try {
            Thread.currentThread().sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("Work is over.");
        phaser.arrive();
    }
}

Once the work of worker is over it will call arrive method on phaser to notify that this particular worker is done with the work and has arrived on that particular phase. The phaser is a mix of CyclicBarrier and CountDownLatch and when one phase is over, it starts a new phase and the limit is Integer.MAX_VALUE. Once it reaches max value it rounds off to zero and starts again. The producer can be written as:
public class WorkProducerUsingPhaser implements Runnable{
    private final Phaser phaser;
    private final ExecutorService executorService;

    public WorkProducerUsingPhaser() {
        phaser = new Phaser();
        executorService = Executors.newFixedThreadPool(5);
    }

    @Override
    public void run() {
        produceRandomWorkers();
    }

    private void produceRandomWorkers() {
        Random random = new Random();
        int numberOfWorkers = random.nextInt(20) + 1;
        System.out.println("Workers count: " + numberOfWorkers);

        phaser.register();

        for (int i=0; i<numberOfWorkers; i++){
            phaser.register();
            executorService.submit(getWorker());
        }

        phaser.arriveAndAwaitAdvance();

        // Now all workers are definitely over.
        try {
            processAfterWorkIsOver();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (ExecutionException e) {
            e.printStackTrace();
        }
    }

    private Thread getWorker() {
        WorkerThread workerTask = new WorkerThread(phaser);
        Thread thread = new Thread(workerTask);
        return  thread;
    }

    private void processAfterWorkIsOver() throws InterruptedException, ExecutionException {
        System.out.println("Work is over by all workers.");
    }
}

Here I have used a thread pool of 5 (you can take any suitable number) and submit all worker threads to ExecutorService. The producer along with all workers is registered to Phaser and then it waits by calling arriveAndAwaitAdvance method. Once every worker is done it calls method arrive and when the last worker calls this method producer is notified and then producer can move ahead. A new phase will also start. This solution seems more clean and suits better.

That is all and I hope you liked it. Please drop your feedback in comments.

Sunday, April 12, 2015

Overview of Enum in Java

As per the doc "An enum type is a special data type that enables for a variable to be a set of predefined constants. The variable must be equal to one of the values that have been predefined for it. " There are various examples for it:
  • List of directions e.g. east, west, north and south
  • Set of Suits in a deck of card: clubs, diamonds, spades, hearts.
  • Rank in a deck of card: ace, duce, three etc.
  • Supported currency in a stock application: dollar, rupee, yen etc.
  • Supported operating systems by a backup application: windows, unix, ubuntu etc.
Consider the following enum which lists the supported operating systems for a product:
public enum SupportedOS {
    WINDOW, UNIX;
}

The concerned product can be installed only on windows and unix. This may be used by product installer class as:
public class ProductInstaller {
   SupportedOS supportedOS;

    public ProductInstaller(SupportedOS supportedOS) {
        this.supportedOS = supportedOS;
    }

    public void install() {
        switch (supportedOS) {
            case WINDOW:
                installRoutineForWindows();
                break;
            case UNIX:
                installRoutineForUnix();
                break;
        }
    }

    private void installRoutineForUnix() {
        // code for installation for Unix
    }

    private void installRoutineForWindows() {
        // code for installation for Windows
    }
}

Where should I use an Enum?
When a variable can take one of the values from a small set of predefined values then using an Enum may make sense. One classical example of using enum is writing thread-safe singleton as mentioned in Effective Java.

What is an EnumSet?
If we use enums and want to allows a set of values then we should use EnumSet but all the values must come from a single enum that is specified when the set is created.

Why should I prefer an Enum?
Suppose in the above example we are passing the OS in string form:
public class ProductInstaller {
   String supportedOS;

    public ProductInstaller(String supportedOS) {
        this.supportedOS = supportedOS;
    }

    public void install() {
        switch (supportedOS) {
            case "WINDOW":
                installRoutineForWindows();
                break;
            case "UNIX":
                installRoutineForUnix();
                break;
        }
    }

    private void installRoutineForUnix() {
        // code for installation for Unix
    }

    private void installRoutineForWindows() {
        // code for installation for Windows
    }
}

Now user can pass even an operation system for which product has no installation support, worse (s)he can pass any random string. So using an Enum provides
  • provides type safety and better compile time error checking. 
  • passing an enum as parameter makes it self-documented in sense that one of the possible values from that enum can only be passed.
  • also avoid errors in passing invalid constants. We can also document legal use cases to use with this enum.
  • By using an enum we can print more sensible value if we override toSring method in it.
  • also helpful in case of auto completion when using an IDE e.g. IntelliJ IDEA.
  • when we create an enum compiler also adds some helpful methods e.g. values that returns an array containing all of the values of the enum in the order they are declared.
Why an enum cannot extend anything else?
Because all enums explicitly extend java.lang.enum and a class can only extend one class in Java.

How enum differs from class?
Enum is similar to a regular class but it always has private constructor. We also get some additional supporting methods like values, valueof etc. Also intent with an enum is different from a class as we want to have fixed number of instances in case of an enum but not in case of a class.

Are fields of an enum implicitly final?
No they are not. Consider the following example:
public class MainTest {
    enum Product {
        PRODUCT_ONE(1.1),PRODUCT_TWO(2.1),PRODUCT_THREE(3.1);

        private double version;

        Product(double version) {
            this.version = version;
        }

        @Override
        public String toString() {
            switch (this) {
                case PRODUCT_ONE:
                    System.out.println("Version of PRODUCT_ONE: " + version);
                    break;
                case PRODUCT_TWO:
                    System.out.println("Version of PRODUCT_TWO: " + version);
                    break;
                case PRODUCT_THREE:
                    System.out.println("Version of PRODUCT_THREE: " + version);
                    break;
            }
            return super.toString();
        }
    }

    public static void main(String[] args) {
        System.out.println(Product.PRODUCT_ONE);
        Product.PRODUCT_ONE.version = 1.3;
        System.out.println(Product.PRODUCT_ONE);
    }
}

The output would be:
Version of PRODUCT_ONE: 1.1
PRODUCT_ONE
Version of PRODUCT_ONE: 1.3
PRODUCT_ONE

Generally we would not create mutable enums but some examples are still there e.g. lazy initialization (when we need to compute some field value when they are first used), a regular singleton object e.g. Registry etc. In most cases enum objects would be immutable and their fields be final. We can also use reflection to examine enum.

Why an enum cannot have public or protected constructor?
An enum must have package-private or private access constructor. We can think Enum as a class with fixed number of instances and the number is not going to change at run time. We provide public or protected constructors when we allow more instances to be created and now it seems to make sense that we do not need public or protected constructors. An enum automatically creates the constants at the beginning of enum body and we cannot invoke an enum constructor our-self.

Can we declare an Enum inside a method?
An enum can be declared inside or outside of a class but not in a method.As per the doc:Nested enum types are implicitly static. It is permissible to explicitly declare a nested enum type to be static. This implies that it is impossible to define a local enum, or to define an enum in an inner class.

Can we mark an Enum final?
As mentioned above all nested enums are implicitly static. But we cannot mark an enum declared outside of a class as any of the following: static, abstract, final, protected or private.

How can we ensure that all enum values are used?
In one of the projects we are using Enum to specify appliance type which can have various possible values e.g. Red Hat Linux, SUSE, Windows etc.
public enum ApplianceType {
    APPLIANCE_TYPE_RHL("LinuxBox"),APPLIANCE_TYPE_SUSE("SuseBox"),APPLIANCE_TYPE_WIN("WinBox"), APPLIANCE_TYPE_UBUNTU("Ubuntu");

    private final String applianceType;

    ApplianceType(String applianceType) {
        this.applianceType = applianceType;
    }

    @Override
    public String toString() {
        return applianceType;
    }
}

And then there is a service which will do processing specific to the appliance. Here is the stripped down version:
public class ApplianceService {
    public static void initializeAppliances(ApplianceType applianceType) {
        if(ApplianceType.APPLIANCE_TYPE_RHL == applianceType) {
            // Do some processing specific to Red Hat Appliance.
        }
        else if(ApplianceType.APPLIANCE_TYPE_SUSE == applianceType) {
            // Do some processing specific to SUSE Appliance.
        }
        else if(ApplianceType.APPLIANCE_TYPE_WIN == applianceType) {
            // Do some processing specific to Windows Appliance.
        }
        System.out.println("Initialization over for appliance type: "+applianceType);
    }

    public static void main(String[] args) {
        initializeAppliances(ApplianceType.APPLIANCE_TYPE_RHL);
    }
}

Now everything is fine till here. Now after some time a new appliance gets introduced e.g. Ubuntu appliance and now we need to scan the code to introduce code for this new kind of appliance. This feels like code smell and needs to be handled. The objective is to ensure that every enum value is used.

The point to observe is every enum should have processing method so we can introduce an abstract method in enum itself and next thing is to ensure that every enum value will provide implementation for that method.
package enums;

public enum ApplianceType {
    APPLIANCE_TYPE_RHL("LinuxBox") {
        @Override
        public void initializeAppliance() {
           // code to initialize RHL.
        }
    },APPLIANCE_TYPE_SUSE("SuseBox") {
        @Override
        public void initializeAppliance() {
            // code to initialize Suse.
        }
    },APPLIANCE_TYPE_WIN("WinBox") {
        @Override
        public void initializeAppliance() {
            // code to initialize Windows.
        }
    }, APPLIANCE_TYPE_UBUNTU("Ubuntu") {
        @Override
        public void initializeAppliance() {
            // code to initialize Ubuntu.
        }
    };

    private final String applianceType;

    ApplianceType(String applianceType) {
        this.applianceType = applianceType;
    }

    // Force them all to implement doProcessing.
    public abstract void initializeAppliance();

    @Override
    public String toString() {
        return applianceType;
    }
}

Now next time we introduce a new appliance type that must also implement the abstract method else it will not compile. Another option is to declare an interface and make sure the enum implements this interface.
public interface ApplianceInitializer {
    public void initializeAppliance();
}

public enum ApplianceType implements ApplianceInitializer{
    APPLIANCE_TYPE_RHL("LinuxBox") {
        @Override
        public void initializeAppliance() {
           // code to initialize RHL.
        }
    },APPLIANCE_TYPE_SUSE("SuseBox") {
        @Override
        public void initializeAppliance() {
            // code to initialize Suse.
        }
    },APPLIANCE_TYPE_WIN("WinBox") {
        @Override
        public void initializeAppliance() {
            // code to initialize Windows.
        }
    }, APPLIANCE_TYPE_UBUNTU("Ubuntu") {
        @Override
        public void initializeAppliance() {
            // code to initialize Ubuntu.
        }
    };

    private final String applianceType;

    ApplianceType(String applianceType) {
        this.applianceType = applianceType;
    }

    @Override
    public String toString() {
        return applianceType;
    }
}

This implementation will also ensure that all values of a enum are used. But this is more flexible in the sense that the interface can be implemented by other classes as well (in case we need it).

Thats all folks! Please leave your feedback in comments.

Saturday, April 4, 2015

What are nested classes and why do we need them?

If a class A is declared inside another class B then that class A is a nested class. It is a member of enclosing class. If a nested class is marked static then it is called static nested class and if it not then it is called non-static nested class or inner class.

There is nothing called top level static class or static inner class. We only have static nested class.

Why do we need nested class?
As per Oracle's official page:
  1. If a class is useful to only one other class then it seems logical to embed this class as a nested class. For example if a class RedBlackNode (represents node of a Red Black Tree) is used only by class RedBlackTree then it makes sense to make RedBlackNode a nested class in the class RedBlackTree.So it is a  way of logically grouping classes that are only used in one place.
  2. A nested class increases encapsulation. Consider a class A whose members are declared private, but class B needs to access them. In that case we can hide class B in A and B can access members of A in spite of the fact that they are private. Also B can be hidden from outside world when declared private.
  3. It can lead to more readable and maintainable code.
A static nested class  interacts with the instance members of its outer class (and other classes) just like any other top-level class. In effect, a static nested class is behaviourally a top-level class that has been nested in another top-level class for packaging convenience.

Is nested class violation of encapsulation?
Some developers feel that nested class is an extreme violation of nested class. IMO this feature is safe if it is used safely. It is not a violation of encapsulation and does not violate programming principle. As I mentioned above nested class B (when declared private) is hidden from outside world and it needs to be part of class A in some ways, also members of class A are still private, so IMO it is perfectly fine and follows Single Responsibility Principle. If you are not sure whether you need a nested class or not then I believe it is better to avoid them, but if you really need them then it is fine to use them.

How do we use static nested class and non-static nested class (inner class)?
Static nested classes are always accessed using the enclosing class's name.
OuterClass.StaticNestedClass nestedObject = new OuterClass.StaticNestedClass();

An instance of inner class (non-static class) can exist only with in an instance of Outer class.
OuterClass.InnerClass innerObject = outerObject.new InnerClass();

Types of Non-static nested class (Inner Class)
There are two types: anonymous and local. We generally use an anonymous class (class with no name) when we create an instance of a class with some overloading of a method, without having to subclass a class. We can simply instantiate anonymous inner class without making a separate class. The classical example of anonymous class is initializing an anonymous class for Runnable interface:
Thread thread = new Thread(new Runnable() {
        @Override
        public void run() {
            System.out.println("New Thread started.");
        }
    });

IMO, after Java 8 it makes more sense to make use of Lambda expression in such places to replace anonymous class as below:
Thread thread = new Thread(() -> System.out.println("New Thread started"));

Another type is local class. Local classes are classes that are defined in a block, which is a group of zero or more statements between balanced braces. We typically find local classes defined in the body of a method.
public class ValidateUser {
    public void validateEmails(String emailId, String alternativeEmailId) {

        final int emailIdLength = 20;

        class Email {

            String formattedEmail;

            Email(String email) {
                 if(email.length() == emailIdLength) 
                    formattedEmail = email;
                else
                    formattedEmail = null;
            }

            public String getFormattedEmail() {
                return formattedEmail;
            }

            // Valid in JDK 8 and later
            public void printOriginalEmailId() {
                System.out.println("Original email id is: " + emailId);
            }

        }

        Email email = new Email(emailId);
        if(email.getFormattedEmail() == null) {
            System.out.println("Email is invalid");
        }

        Email alternativeEmail = new Email(alternativeEmailId);
        if(alternativeEmail.getFormattedEmail() == null) {
            System.out.println("Alternative email is invalid");
        }
        
    } // method validateEmails ends here.
}

In the above example method validateEmails validates the emails provided by the user. It defines a local inner class Email to represent the email-id for a user. A local class has access to members of enclosing class. It also has access to local variables that are declared final. In the above example field emailIdLength is final and can be accessed in the constructor of the local class Email.

However starting in Java 8 there are two changes:
  1. A local class can access local variables and parameters of the enclosing block that are final or effectively final. A variable or parameter whose value is never changed after it is initialized is effectively final. Suppose the variable emailIdLength is not final and its value is changed in the constructor of local class Email, in that case this variable is not effectively final and compiler will complain.
  2. If we declare the local class in a method it can access the parameters of the enclosing method. In the above example the method printOriginalEmailId was able to access the method parameter emailId.
Actually anonymous classes are like local classes except that they do not have a name. We should use them if you need to use a local class only once.

Should I always mark a nested class static?
As Jon Skeet points out, it is a better idea if we need a nested class then to start with a static nested class and then decide if it really needs to be non-static (inner class) based on the usage. Whenever we see an inner class we need to decide whether we really need it with extra complexity and implicit (rather than explicit and more clean) reference to the outer containing class?

If an instance of inner class is strongly referenced then the outer instance is strongly referenced too. This can lead to some confusion when the outer instance is not garbage collected even though it appears that nothing references it. We must remember that an inner class maintains an implicit reference to the instance of outer class.


How to figure out if we need an inner class (non-static nested class) ?
The point to note is: Inner classes are not allowed to have static methods or fields. If we feel that we are passing a lot of stuff in the constructor of a top level class then it is an hint that we can make use of an inner class. An inner class can see all the fields of the outer class, it means we don't have to deal with the outer class fields as if they come from an outer class.

Difference between static nested class and non-static nested (inner class) class

Static Nested classNon-static nested class (Inner class)
Does not need instance of outer class as it is not associated with any instance of outer class.Needs instance of outer class for initialization.
Uses static keyword so it means it is static member of the outer class and can be accessed like that.Not a static member and every instance of inner class needs an implicit reference to instance of outer class.
Nested classes can be imported using static imports in Java.Not applicable.
Should be preferred for obvious reasons

Can we mark the nested classes final?
First of all we need to understand that static keyword can only be applied to a nested class and not to outer class. If we make anything final then it becomes constant, something that is final value and cannot be changed any further by any means. If a class is final then it simply means it cannot be inherited. So if we mark a nested class (static or non-static) final then it cannot be inherited, like any regular final class.

Can we extend nested class (static or inner)?
Yes we can extends both of them. Consider the following class which contains one static nested class and one inner class.
public class OuterClass {
    static class StaticNestedClass {
        void display() {
            System.out.println("Inside StaticNestedClass");
        }
    }
    class InnerClass {
        void display() {
            System.out.println("Inside InnerClass");
        }
    }
}

The following class extends Outerclass and its nested class also extends respective nested classes:
public class OuterClassDerivedClass extends OuterClass{
    static class StaticNestedDerivedClass extends OuterClass.StaticNestedClass {
        @Override
        void display() {
            System.out.println("Inside StaticNestedDerivedClass");
        }
    }
    class InnerDerivedClass extends OuterClass.InnerClass {
        @Override
        void display() {
            System.out.println("Inside InnerDerivedClass");
        }
    }
}

Now we can test these classes as:
public class InheritanceTest {
    public static void main(String[] args) {
        OuterClass outerClass = new OuterClass();
        OuterClass.InnerClass innerClass = outerClass.new InnerClass();
        innerClass.display();
        OuterClass.StaticNestedClass staticNestedClass = new OuterClass.StaticNestedClass();
        staticNestedClass.display();

        OuterClassDerivedClass outerClassDerivedClass = new OuterClassDerivedClass();
        OuterClassDerivedClass.InnerDerivedClass innerDerivedClass = outerClassDerivedClass.new InnerDerivedClass();
        innerDerivedClass.display();
        OuterClassDerivedClass.StaticNestedDerivedClass staticNestedDerivedClass = new OuterClassDerivedClass.StaticNestedDerivedClass();
        staticNestedDerivedClass.display();
    }
}

As expected the output will be:
Inside InnerClass 
Inside StaticNestedClass 
Inside InnerDerivedClass 
Inside StaticNestedDerivedClass

Can a Java File contain more than one public class?
A Java file can contain only one public class except for public nested classes. Check the class below:
public class Sample {
    public class InnerClassOne {
        public void display() {
            System.out.println("In class innerClassOne");
        }
    }
    public class InnerClassTwo {
        public void display() {
            System.out.println("In class innerClassTwo");
        }
    }
    static public class StaticNestedClassOne {
        public void display() {
            System.out.println("In class StaticNestedClassOne");
        }
    }
    static public class StaticNestedClassTwo {
        public void display() {
            System.out.println("In class StaticNestedClassTwo");
        }
    }
}

This can be tested as:
Sample sample = new Sample();
Sample.InnerClassOne innerClassOne = sample.new InnerClassOne();
Sample.InnerClassTwo innerClassTwo = sample.new InnerClassTwo();

Sample.StaticNestedClassOne staticNestedClassOne = new Sample.StaticNestedClassOne();
Sample.StaticNestedClassTwo staticNestedClassTwo = new Sample.StaticNestedClassTwo();

innerClassOne.display();
innerClassTwo.display();
staticNestedClassOne.display();
staticNestedClassTwo.display();

Can a nested class extend its outer class itself?
Yes it can. If we look inside the class Arc2D in java.awt.geom package, we will notice that it has static nested class Float and Double which extend the outer class itself.
public abstract class Arc2D extends RectangularShape {
  public static class Float extends Arc2D implements Serializable { .. }
  public static class Double extends Arc2D implements Serializable { .. }
}

This is done to logically group the classes and their logic. If a user wishes to use abstract class Arc2D then it is helpful to find the implementations that they can use in the class itself.

In the similar way a non-static nested class or inner class can also extend its own outer class.But why would we want an inner class to extend its outer class?  For example we can have an outer class Car which can have an inner class Wheel and every instance of Car must be having an instance of Wheel. Now it does not make conceptual sense for an inner class to extend its outer class. IMO that would be a problematic design and should be avoided.

References:
https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html
http://mindprod.com/jgloss/nestedclasses.html#INHERITANCE

Thursday, April 2, 2015

Default methods in Java

Default methods were added in Java 8. They are also known as defender methods or virtual extension methods. The prime purpose for addition of these methods is to allow us to add new functionality to existing interfaces in old libraries and to make sure the code is also binary compatible with those interfaces.

When an interface contains a default method and another interface extends this interface we can do one of the following:
  • We do not mention the default method and in that case that default method is inherited by new interface.
  • We can re-declare the method and now this is abstract.
  • We can redefine the method and now it is overridden.
One aspect where confusion generally arises is the diamond pattern where a class implements two interfaces and both the interfaces define a method with same signature. Consider the following example:
public interface Engine {  
    default void start(){  
        System.out.println("Starting engine Engine.start()");  
    }  
}

public interface CNGKit {
    default void start(){
        System.out.println("Starting CNG Kit CNGKit.start()");
    }
}

public class Car implements Engine, CNGKit {

}

A car can have both an engine and a CNG Kit and in that case we need to specify whether the car should run on engine (petrol or diesel) or it should run using CNG Kit. This example is just used to explain the concept and not an ideal representation of OOP concepts. This will not compile and we need to resolve it manually by overriding the conflicting method as:
public class Car implements Engine, CNGKit {
 public void start(){
        Engine.super.start();
    }
}

What is the motivation of adding default methods in Java?
  1. They provide option to extend existing libraries by providing new methods and also ensure binary compatibility. An example is the addition of forEach method to Collection where the default implementation is written in terms of iterator method.
  2. They provide flexibility to allow an interface to define method implementations that will work as default in case a concrete class (implementation of this interface) fails to provide an implementation for this default method.
  3. Due to default methods, an interface can stay as a functional interface even if it has more than one method. A Functional Interface has only one non-default abstract method which can be implemented using a lambda expression.
Regarding the last point consider an example of functional interface Predicate which has only one non-default abstract method test. But it provides default methods for negating a predicate or combining it with another predicate. Without default methods these methods had to be provided in another utility class like the pre-Java 8 Collections class (as we don’t want to give up the possibility of lambda implementations for such an interface).

Why default methods cannot be declared final?
Consider the following abstract class Dispatcher which can be used to dispatch an event with empty message or an event with specific message:
abstract class Dispatcher {
    final void dispatchMessage() {
        dispatchMessage(null);
    }
    abstract void dispatchMessage(String message);
}
The method declared final is a convenience method to dispatch an empty message where as other method should be implemented by implementation classes. We can think of using an interface like following, if default methods were allowed to be final:
public interface IDispatcher {
    default final void dispatchMessage() {
        dispatchMessage(null);
    }
    void dispatchMessage(String message);
}

Now it seems like a good use case then how come they were not allowed to be declared final?

First: We need to understand the primary goal for taking the decision of adding default methods. It was interface evolution and not turning them into traits. The idea behind a default method is that it is an interface method which will be used if the derived class does not provide any specific implementation for it. If the derived class provides one then in that case the specific implementation will be used.

Again the purpose of default methods is interface evolution, and if a default method is allowed to be declared final then that would not be the default implementation rather it would be the only implementation.

Second: another use case is of diamond problem I explained where both classes (Engine and CNGKit) were having same default method start. Suppose if class CNGKit makes its default method final and class Engine is not under our control (may be third party or any other reason) then our class C is irretrievably broken because it cannot compile without overriding start() but it cannot because start() is final in CNGKit. Actually final methods make more sense for single-inheritance classes than for interfaces which can lead to multiple inheritance.

Third: The default implementation of a default method is only considered if the class (or superclass) does not provide any (abstract or concrete) declaration of the method. If a default method were declared final but one of the super-classes already implemented it then this default method will be ignored. And that is probably not the intention when we were trying to mark the default method final.

Default methods were meant for API evolution but is it wrong to use them in new interfaces?
IMO every feature of a language is right if its used in a right manner. Suppose we are having certain convenience methods which are generally implemented as non-default methods by all the classes. Consider an example of logging which has a convenience method to log and is implemented by each class. This method can be declared as default in an interface ILoggable and every class can implement it.
public interface ILoggable {
    default Logger logger() {
        return LoggerFactory.getLogger(this.getClass());
    }
}

In this example the method is strictly for convenience and can be an ideal fit for default method. As explained by Brian Goetz, the default methods fit the following use cases:
  1. Interface Evolution: We all agree to it.
  2. Optional methods: Implementors need not to implements these methods if they can live with default implementation e.g. Iterator.remove method is given a default and most of the implementations of Iterator have this behavior.
  3. Convenience methods: The methods that are strictly for convenience and again they are implemented as non-default methods on the class. An example is of logger given above.
  4. Combinators: These are the methods which create new instances of an interface based on the current instance. The examples are methods Predicate.and() and Comparator.thenComparing()
Why default methods cannot be declared synchronized?
Actually we cannot mark any method (default/static or whatever) in an interface synchronized. We can have a synchronize block within the default (or static) method but marking the method itself synchronized is not allowed.

Locking is all about coordinating the shared access to a mutable state. Each object should have a synchronization policy to figure out which lock guards the state of this object.  Many objects use Java Monitor Pattern where the state of the object is guarded by the intrinsic lock. The synchronized keyword on a method implicitly assumes this pattern. So the synchronization policy is determined by the state and state is owned by the class and not by an interface. If we use synchronized method in an interface it assumes a particular synchronization policy but we have no reasonable basis for assuming this. It would give us false sense of thread-safety and no error message would tell us that we are assuming wrong synchronization policy.

It is already tough to maintain synchronization policy for a single source file, for interfaces we can have multiple classes implementing it and in that case making sure that a subclass follows the synchronization policy defined by super class would be really hard.

Why synchronized cannot be used with a regular method?
Actually synchronized is an implementation detail. One implementation of the method might need to make the method synchronized where as the other one might not. The caller of the method does not care whether the method is synchronized or not. It is not part of the contract which explains what the method does. So synchronized does not belong to an interface rather to the concrete implementation of the interface.

Why we cannot define a default method for a method from Object class?
In some scenarios it may seem good idea to define default version of methods like toStream from Object class. But this is not allowed. This mail covers a lot of interesting stuff on this subject. There were many design decisions:
To keep interface model simple.
Inheriting  the methods equals/hashCode/toString is strongly tied to single inheritance and interfaces support multiple inheritance and are also stateless.
It can lead to some surprising behaviors.

When we talk about inheritance and conflict resolutions rules are simple:
  1. Classes win over interfaces.
  2. Derived interfaces win over super interfaces. A default from List wins over a default from Collection.
The methods (equals/hashCode/toString) are all about state of the object and the class owns the state, not the interface. And class is in a better position to determine what equality means for the class (see Effective Java for equality). Defaults should act as defaults only they should not change the semantics of concrete implementing classes. But in this case it wont be true.

Why default methods cannot be static?
First think why would you really need them? Default methods provide default implementation which can be overridden by implementation classes, if we declare them static will it be possible? And if you have the intention that the method cannot be overridden by implementation classes then why don't we mark it static all the way?

With advent of default methods they seem like abstract class only. Why were these methods added in first place?
To check the difference between abstract class and interface check this post. The motivation for them is already explained and a good example for them is we can use
list.sort(ordering);
instead of
Collections.sort(list, ordering);

That's all for now. Enjoy!