Training Institute in Electronic City Bangalore

Training Institute in Electronic City Bangalore
Training Institute in Electronic City Bangalore

Explain CyclicBarrier in Java?

CyclicBarrier in Java is a synchronizer introduced in JDK 5 on java.util.Concurrent package along with other concurrent utility like Counting Semaphore, BlockingQueue, ConcurrentHashMap etc.

CyclicBarrier is similar to CountDownLatch which allows multiple threads to wait for each other (barrier) before proceeding. CyclicBarrier is a natural requirement for a concurrent program because it can be used to perform final part of the task once individual tasks are completed.

All threads which wait for each other to reach barrier are called parties, CyclicBarrier is initialized with a number of parties to wait and threads wait for each other by calling CyclicBarrier.await() method which is a blocking method in Java and  blocks until all Thread or parties call await().

In general calling await() is shout out that Thread is waiting on the barrier.
await() is a blocking call but can be timed out or Interrupted by other thread.

If you look at CyclicBarrier, it also the does the same thing but there is different you cannot reuse CountDownLatch once the count reaches zero while you can reuse CyclicBarrier by calling reset () method which resets Barrier to its initial State.

What it implies that CountDownLatch is a good for one-time events like application start-up time and CyclicBarrier can be used to in case of the recurrent event e.g. concurrently calculating a solution of the big problem etc.

Example

Here is a simple example of CyclicBarrier in Java on which we initialize CyclicBarrier with 3 parties, means in order to cross barrier, 3 thread needs to call await() method.

Each thread calls await method in short duration but they don't proceed until all 3 threads reached the barrier, once all thread reach the barrier, barrier gets broker and each thread started their execution from that point.
It’s much clear with the output of following example of CyclicBarrier in Java:


import
 java.util.concurrent.BrokenBarrierException;
import 
java.util.concurrent.CyclicBarrier;
import 
java.util.logging.Level;
import 
java.util.logging.Logger;

/**
 * Java 
program to demonstrate how to use CyclicBarrier in Java. CyclicBarrier is a
 * new Concurrency Utility added in Java 5 Concurrent package.
 *
 */

public class CyclicBarrierExample 
{

    
//Runnable task for each thread
    private static class Task implements 
Runnable {

        private CyclicBarrier barrier
;

        public Task
(CyclicBarrier barrier) {
            this.
barrier = barrier;
        
}

        @Override
        public 
void run() {
            try 
{
                System.
out.println(Thread.currentThread().getName() + " is waiting on barrier");
                barrier.
await();
                System.
out.println(Thread.currentThread().getName() + " has crossed the barrier");
            
} catch (InterruptedException ex) {
                Logger.
getLogger(CyclicBarrierExample.class.getName()).log(Level.SEVERE, null, ex);
            
} catch (BrokenBarrierException ex) {
                Logger.
getLogger(CyclicBarrierExample.class.getName()).log(Level.SEVERE, null, ex);
            
}
        
}
    
}

    public static 
void main(String args[]) {

        
//creating CyclicBarrier with 3 parties i.e. 3 Threads needs to call await()
        final CyclicBarrier cb = new CyclicBarrier
(3, new Runnable(){
            @Override
            public 
void run(){
                
//This task will be executed once all thread reaches barrier
                System.
out.println("All parties are arrived at barrier, lets play");
            
}
        
});

        
//starting each of thread
        Thread t1 = new Thread
(new Task(cb), "Thread 1");
        Thread t2 = new Thread
(new Task(cb), "Thread 2");
        Thread t3 = new Thread
(new Task(cb), "Thread 3");

        t1.
start();
        t2.
start();
        t3.
start();
      
    
}
}


Output:
Thread 
1 is waiting on barrier
Thread 
3 is waiting on barrier
Thread 
2 is waiting on barrier
All parties have arrived at barrier, lets 
play
Thread 
3 has crossed the barrier
Thread 
1 has crossed the barrier
Thread 
2 has crossed the barrier


When to use CyclicBarrier in Java

Given the nature of CyclicBarrier it can be very handy to implement map reduce kind of task similar to fork-join framework of Java 7, where a big task is broken down into smaller pieces and to complete the task you need output from individual small task
 e.g. to count population of India you can have 4 threads which count population from North, South, East, and West and once complete they can wait for each other, When last thread completed their task, Main thread or any other thread can add result from each zone and print total population. You can use CyclicBarrier in Java :
1.    To implement multi player game which cannot begin until all player has joined.
2.    Perform lengthy calculation by breaking it into smaller individual tasks, In general, to implement Map reduce technique.

Important point of CyclicBarrier in Java

1.    CyclicBarrier can perform a completion task once all thread reaches to the barrier, this can be provided while creating CyclicBarrier.
2.    If CyclicBarrier is initialized with 3 parties means 3 thread needs to call await method to break the barrier.
3.    The thread will block on await() until all parties reach to the barrier, another thread interrupt or await timed out.
4.    If another thread interrupts the thread which is waiting on barrier it will throw BrokernBarrierException as shown below:


java.util.concurrent.BrokenBarrierException
              at java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:172)
at java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:327)


5.    CyclicBarrier.reset() put Barrier on its initial state, other thread which is waiting or not yet reached barrier will terminate with java.util.concurrent.BrokenBarrierException.


[Multithreading Interview Questions]


We recommend you take Big Data Hadoop class room training at eMexo Technologies in electronic city, Bangalore to learn more about Big Data Hadoop.

Difference between Loose Coupling and Tight Coupling in Java?

First to understand what is Loose coupling and Tight coupling and also to know the advantage of loose coupling.    
 In short Loose coupling means reducing dependencies of a class that use different class directly. Tight coupling means classes and objects are dependent on one another. In general tight coupling is usually not good because it reduces flexibility and re-usability of code and it makes changes much more difficult and not easy to test.

1. Tight Coupling

Tightly coupled object is an object that needs to know quite a bit about other objects and are usually highly dependent on each other's interfaces. Changing one object in a tightly coupled application often requires changes to a number of other objects. In a small application we can easily identify the changes and there is less chance to miss anything. But in large applications these inter-dependencies are not always known by every programmer and there is chance of overlooking changes.
See below code is for tight coupling. 
public class Journey {
                Car car = new Car();
                public void startJourney() {
                        car.travel();
                }
        }

       public class Car {
              public void travel () {
                      System.out.println("Travel by Car");
              }
       }
       
In the above code the Journey class is dependents on Car class to provide service to the end user(main class to call this Journey class).
In the above case Journey class is tightly coupled with Car class it means if any change in the Car class requires Journey class to change. For example if Car class travel() method change to journey() method then you have to change the startJourney() method will call journey() method instead of calling travel() method.
See below code, 
       public class Journey {
                Car car = new Car();
                public void startJourney() {
                        car.journey();
                }
        }

       public class Car {
              public void journey () {
                      System.out.println("Travel by Car");
              }
       }
     
The best example of tight coupling is RMI(Remote Method Invocation)(Now a days  every where using web services and SOAP instead of using RMI, it has some disadvantages).

2.   Loose Coupling

Loose coupling is a design goal that seeks to reduce the inter-dependencies between components of a system with the goal of reducing the risk that changes in one component will require changes in any other component. Loose coupling is much more generic concept intended to increase the flexibility of system, make it more maintainable and makes the entire framework more stable.
Below code is an example of loose coupling.
         public interface Vehicle {
                  void start();
         }
        
        public class Car implements Vehicle {
                @Override
                 public void start() {
                          System.out.println("Travel by Car");
                 }
         }

       public class Bike implements Vehicle {
                @Override
                 public void start() {
                          System.out.println("Travel by Bike");
                 }
       }
             // create main class Journey
       public class Journey {
               public static void main(String[] args) {
                       Vehicle v = new Car();
                        v.start();
               }
        }

In the above example, Journey and Car objects are loosely coupled. It means Vehicle is an interface and we can inject any of the implemented classes at run time and we can provide service to the end user.
The examples of Loose coupling are Interface, JMS, Spring IOC(Dependency Injection, it can reduce the tight coupling).

Advantages of Loose coupling

A loosely coupled will help you when your application need to change or grow. If you design with loosely coupled architecture, only a few parts of the application should be affected when requirements change. With too a tight coupled architecture, many parts will need to change and it will be difficult to identify exactly which parts will be affected. In short,
 1) It improves the testability.                                                                        
 2) It helps you follow the GOF principle of program to interfaces, not implementations.
 3) The benefit is that it's much easier to swap other pieces of code/modules/objects/components when the pieces are not dependent on one another.

 4) It's highly changeable. One module doesn't break other modules in unpredictable ways.


We recommend you take Big Data Hadoop class room training at eMexo Technologies in electronic city, Bangalore to learn more about Big Data Hadoop.

JUnit Tutorial

Unit testing is a common practice in test-driven development (TDD)

Java code can be unit tested using a code-driven unit testing framework. The following are a few of the available code-driven unit testing frameworks for Java.

1.    SpryTest
2.    Jtest
3.    JUnit
4.    TestNG 

JUnit is the most popular and widely used unit testing framework for Java. It allows developers to unit test the code elegantly. Apparently, TestNG is cleaner than JUnit, but JUnit is far more popular than TestNG. JUnit has a better mocking framework support such as Mockito, which offers a custom JUnit 4 runner.


JUnit 4 is an annotation-based, flexible framework.The following are the advantages of JUnit 4 over its predecessor:
·         Instead of inheriting from junit.framework.Testcase, any class can be a test class. It doesn't force you to extend the TestCase class.
·         The setUp and tearDown methods are replaced by the @before and @after annotations
·         Any public method annotated as @test can be a test method


Exploring annotations

1.   @Test
          The @Test annotation represents a test. Any public method can be annotated with the @Test annotation with @Test to make it a test method. There's no need to start the method name with test.

          Example:
            @Test
       public void someTest2() {
            System.out.println("\t\t someTest2 is invoked");
      }

2.   @Before and @After
         JUnit 4 provides a @Before annotation. If we annotate any public void method of any name with @Before, then that method gets executed before every test execution. JUnit 3 has a  setUp() method for this purpose.
Similarly, any method annotated with @After gets executed after each test method execution. JUnit 3 has a tearDown() method for this purpose.
3.   @BeforeClass and @AfterClass
        JUnit 4 provides two more annotations: @BeforeClass and @AfterClass. They are executed only once per test class. The @BeforeClass and@AfterClass annotations can be used with any public static void methods. The @BeforeClass annotation is executed before the first test and the@AfterClass annotation is executed after the last test.

@Before and @After can be applied to any public void methods. @AfterClass and @BeforeClass can be applied to only public static void methods.

Running the first unit test

Let's write our first test by performing the following steps:
1. We will create a test class under a test source package. Create a Source folder named test and create a SanityTest.java Java class under package com.packtpub.junit.recap.

It is a good practice to create test classes with a Test suffix. So, a MyClass class will have a MyClassTest test class. Some code coverage tools ignore tests if they don't end with a Test suffix.

2. Add the following code to the SanityTest class:

import org.junit.After;
import org.junit.AfterClass;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;

public class SanityTest {
 
  @BeforeClass
  public static void beforeClass() {
    System.out.println("***Before Class is invoked");
  }

  @Before
  public void before() {
    System.out.println("____________________");
    System.out.println("\t Before is invoked");
  }
  @After
  public void after() {
    System.out.println("\t After is invoked");
    System.out.println("=================");
  }
 
  @Test
  public void someTest() {
    System.out.println("\t\t someTest is invoked");
  }
 
  @Test
  public void someTest2() {
    System.out.println("\t\t someTest2 is invoked");
  }
 
 
  @AfterClass
  public static void afterClass() {
    System.out.println("***After Class is invoked");
  }
}

In the preceding class, we created six methods. Two test methods are annotated with @Test. Note that two methods (beforeClass andafterClass) are static and the other four are nonstatic. A static method annotated with @BeforeClass is invoked only once, that is, before the test class is instantiated, and @AfterClass is invoked after the class is done with all the execution.

 3. Run the test. Press Alt + Shift + X and T or navigate to Run | Run As | JUnit Test. You will see the following console (System.out.println) output:


Check whether the before and after methods are executed before and after every test run. However, the order of the test method execution may vary. In some runs, someTest may be executed before someTest2 or vice versa. The afterClass and beforeClassmethods are executed only once.


Verifying test conditions with Assertion

Assertion is a tool (a predicate) used to verify a programming assumption (expectation) with an actual outcome of a program implementation; for example, a programmer can expect that the addition of two positive numbers will result in a positive number. So, he or she can write a program to add two numbers and assert the expected result with the actual result.
The org.junit.Assert package provides static overloaded methods to assert expected and actual values for all primitive types, objects, and arrays.
The following are the useful assert methods:
        •      assertTrue(condition) or assertTrue(failure message, condition): If the condition becomes false, the assertion fails andAssertionError is thrown. When a failure message is passed, the failure message is thrown.
       assertFalse(condition) or assertFalse(failure message, condition): If the condition becomes true, the assertion fails andAssertionError is thrown.
       assertNull: This checks whether the object is null, otherwise throws AssertionError if the argument is not null.
       assertNotNull: This checks whether the argument is not null; otherwise, it throws AssertionError.
       assertEquals(string message, object expected, object actual), or assertEquals(object expected, object actual), orassertEquals(primitive expected, primitive actual): This method exhibits an interesting behavior if primitive values are passed and then the values are compared. If objects are passed, then the equals() method is invoked. Moreover, if the actual value doesn't match the expected value, AssertionError is thrown.
       assertSame(object expected, object actual): This supports only objects and checks the object reference using the == operator. If two different objects are passed, then AssertionError is thrown.
       assertNotSame: This is just the opposite of assertSame. It fails when the two argument references are the same.

We will use the assert methods in the test as follows:

1.   Create a AssertTest test class under com.packtpub.junit.recap. Add the following lines to the class:
package com.packtpub.junit.recap;

import org.junit.Assert;
import org.junit.Test;

public class AssertTest {

  @Test
  public void assertTrueAndFalseTest() throws Exception {
    Assert.assertTrue(true);
    Assert.assertFalse(false);
  }
 
  @Test
  public void assertNullAndNotNullTest() throws Exception {
    Object myObject = null;
    Assert.assertNull(myObject);
   
    myObject = new String("Some value");
    Assert.assertNotNull(myObject);
  }
}
In the preceding code, assertTrueAndFalseTest sends true to assertTrue and false to assertFalse. So, the test should not fail.
In assertNullAndNotNullTest, we are passing null to assertNull and a non-null String to assertNotNull; so, this test should not fail.
Run the tests. They should be green.
2.  We will examine assertEquals and add the following test and static import the assertEquals method:
  import static org.junit.Assert.assertEquals;

  @Test
  public void assertEqualsTest() throws Exception {
    Integer i = new Integer("5");
    Integer j = new Integer("5");;
    assertEquals(i,j);
  }
In the preceding code, we defined two Integer objects, i and j, and they are initialized with 5. Now, when we pass them to assertEquals, the test passes, as the assertEquals method calls i.equals(j) and not i == j. Hence, only the values are compared, not the references.
The assertEquals method works on all primitive types and objects. To verify a double value, either use the overloadedassertEquals(actual, expected, delta) method or just use BigDecimal instead of using Double.
3.  Add a test to verify the assertNotSame behavior and static import the assertNotSame method:
   import static org.junit.Assert.assertNotSame;
  @Test
  public void assertNotSameTest() throws Exception {
    Integer i = new Integer("5");
    Integer j = new Integer("5");;
    assertNotSame(i , j);
  }
The assertNotSame method fails only when the expected object and the actual object refers to the same memory location. Here, i and jhold the same value but the memory references are different.
4.  Add a test to verify the assertSame behavior and static import the assertSame method:
  import static org.junit.Assert.assertSame;
  @Test
  public void assertSameTest() throws Exception {
    Integer i = new Integer("5");
    Integer j = i;
    assertSame(i,j);
  }
The assertSame method passes only when the expected object and the actual object refer to the same memory location. Here, i and j hold the same value and refer to the same location.

Working with exception handling

 To test an error condition, exception handling feature is important. For example, an API needs three objects; if any argument is null, then the API should throw an exception. This can be easily tested. If the API doesn't throw an exception, the test will fail.
The @Test annotation takes the expected=<<Exception class name>>.class argument.
If the expected exception class doesn't match the exception thrown from the code, the test fails. Consider the following code:
  @Test(expected=RuntimeException.class)
  public void exception() {
    throw new RuntimeException();
  }

Ignoring a test

 Instead of commenting a test, we can just ignore it by annotating the test method with @Ignore. Commenting out a test or code is bad as it does nothing but increases the code size and reduces its readability. Also, when you comment out a test, then the test report doesn't tell you anything about the commented-out test; however, if you ignore a test, then the test report will tell you that something needs to be fixed as some tests are ignored. So, you can keep track of the ignored test.
Use @Ignore("Reason: why do you want to ignore?"). Giving a proper description explains the intention behind ignoring the test. The following is an example of, where a test method is ignored because the holiday calculation is not working:
@Test
@Ignore("John's holiday stuff failing")
public void when_today_is_holiday_then_stop_alarm() {
}
You can place the @Ignore annotation on a test class, effectively ignoring all the contained tests. 

Executing tests in order

For example, when you want to write slow tests to insert a row into a database, then first update the row and finally delete the row. Here, unless the insert function is executed, delete or update functions cannot run.

JUnit 4.11 provides us with an @FixMethodOrder annotation to specify the execution order. It takes enum MethodSorters.
To change the execution order, annotate your test class using @FixMethodOrder and specify one of the following available enum MethodSortersconstant:
              MethodSorters.JVM: This leaves the test methods in the order returned by the JVM. This order may vary from run to run.
    MethodSorters.NAME_ASCENDING: This sorts the test methods by the method name in the lexicographic order.
    MethodSorters.DEFAULT: This is the default value that doesn't guarantee the execution order.
We will write a few tests to verify this behavior.
Add a TestExecutionOrder test and create tests, as shown in the following code snippet: 
public class TestExecutionOrder {
  @Test   public void edit() throws Exception {
    System.out.println("edit executed");
  }
  @Test   public void create() throws Exception {
    System.out.println("create executed");
  }
  @Test   public void remove() throws Exception {
    System.out.println("remove executed");
  } 
}
Run the tests. The execution order may vary, but if we annotate the class with @FixMethodOrder(MethodSorters.NAME_ASCENDING), the tests will be executed in the ascending order as follows:
@FixMethodOrder(MethodSorters.NAME_ASCENDING)
public class TestExecutionOrder { … }
The following Eclipse screenshot displays the test execution in the ascending order:


Learning assumptions

Like AssertAssume offers many static methods, such as assumeTrue(condition)assumeFalse(condition),assumeNotNull(condition), and assumeThat(condition). Before executing a test, we can check our assumption using the assumeXXXmethods. If our assumption fails, then the assumeXXX methods throw AssumptionViolatedException, and the JUnit runner ignores the tests with failing assumptions.

Create an Assumption test class. The following is the body of the class:

public class Assumption {
  
  boolean isSonarRunning = false;
  @Test
  public void very_critical_test() throws Exception {
    isSonarRunning = true;
    Assume.assumeFalse(isSonarRunning);
    assertTrue(true);
  }
 
}
Here, for simplicity, we added a isSonarRunning variable to replicate a SONAR server facade. In the actual code, we can call an API to get the value. We will set the variable to false. Then, in the test, we will reset the value to true. This means SONAR is running. So, our assumption that SONAR is not running is false; hence, the test will be ignored.
The following screenshot shows that the test is ignored. We didn't annotate the test using @Ignore:


Exploring the test suite

To run multiple test cases, JUnit 4 provides Suite.class and the @Suite.SuiteClasses annotation. This annotation takes an array (comma separated) of test classes.
Create a TestSuite class and annotate the class with @RunWith(Suite.class). This annotation will force Eclipse to use the suite runner.
Next, annotate the class with @Suite.SuiteClasses({ AssertTest.class, TestExecutionOrder.class, Assumption.class }) and pass comma-separated test class names.
The following is the code snippet: 
import org.junit.runner.RunWith;
import org.junit.runners.Suite;

@RunWith(Suite.class)
@Suite.SuiteClasses({ AssertTest.class, TestExecutionOrder.class,Assumption.class })
public class TestSuite {

}
During execution, the suite will execute all the tests. The following is a screenshot of the suite run. Check whether it runs seven tests out of the three test fixtures: AssertTestTestExecutionOrder, and Assumption.


Working with timeouts

JUnit tests are automated to get quick feedback after a change in the code. If a test runs for a long time, it violates the quick feedback principle. JUnit provides a timeout value (in milliseconds) in the @Test annotation to make sure that if a test runs longer than the specified value, the test fails.
The following is an example of a timeout:
  @Test(timeout=10)
  public void forEver() throws Exception {
    Thread.sleep(100000);
  }

Here, the test will fail automatically after 10 milliseconds.


[Core Java Interview Questions]

We recommend you take Big Data Hadoop class room training at eMexo Technologies in electronic city, Bangalore to learn more about Big Data Hadoop.

© Blogger Templates | Webtalks