Showing posts with label jdk. Show all posts
Showing posts with label jdk. Show all posts

Friday, September 23, 2016

Kick-Off Java 9 (Project Jigsaw) Part - I

Now a day's monolithic applications comes into micro batches. Every micro batch independent from each others and deploy. Now the Java will come in this flavor using project Jigsaw

Java 9 comes with great feature call "Jigsaw", which modularize monolithic Java code into modules. Where we design independently standard modules with in different scopes. Primary goal of "jigsaw" to make scalability, maintainability, performance, security etc. For more information please click on this link.

Today we creating just a greeting example using project "Jigsaw" or modularize our code independently.

Prerequisite


Step - I

Create a source directory for our source code:
$ mkdir -p jigsaw-sample1/src

Step - II

Categories our system into modules like in this example, i have one utility module and other main module. The utility module contains utility classes and main module access that utility class and their methods for performing operations.
jigsaw-sample1/src $ mkdir com.knoldus.util com.knoldus.main
Before jigsaw, we module our project using packages but still we have monolithic structure. Our package conventions is reverse domain of company. Jigsaw still recommend that convention.

From above command we are creating two directories, which is basically our project modularization. These are two independent modules and for packaging, two independent jar. which we will see later.

Thursday, September 22, 2016

Scala Future Under The Hood

In the previous post , i was discussing about Scala ExecutionContext. As we know, for multithreading we need to maintain thread pools using ExecutionContext and by default ForkJoinPool is used because for accessing “multi core” processor. There are multiple thread pools are available in our java.util.concurrent.Executors utility class and as per our requirement we can create new one also.

After all, Scala have concept of Future. Why? In multithreading programming, large or heavy processes were executed on background or in new threads, but the most common problem we are facing is to handle return values from separate thread or handle exceptions or errors. This is the reason, some time developers starts heavy process in synchronized way because we need to access the values after computation and handle exceptions or more.

Note: Scala Future is the rich concept for handling multiple thread and there values after computations or handling error or exceptions if something happen in separate thread.
In scala api’s, Future is a trait and Future also has its companion object which has following apply method.

def apply[T](body: => T) (implicit executor: ExecutionContext): Future[T]
apply method accept future body as named parameter and ExecutionContext as implicit parameter because when future starts to process the body, it will execute the body in separate thread or (asynchronously) by using ExecutionContext.

In simple words, Future is a placeholder, that is, a memory location for the value. This placeholder does not need to contain a value when the future is created. The value can be placed into the future eventually when the processing is done.

Let we assume, i have a method called renderPage and return content of web page as Future[String]:

def renderPage(path: String): Future[String] = {
    Future { ……………….. }
}
When the method calls, the Future singleton object followed by a block is a syntactic sugar for calling the Future.apply method. The Future.apply method acts similar as asynchronously. Its starts process in separate thread and render the content of webpage and place the webpage content into the Future when they become available. Following is the just a conceptual diagram for this example:

Thread and Space (3)

This removes blocking from the renderPage method, but it is not clean how the calling thread can extract the content from Future ?

Polling is one of way , In which the calling thread calls a special method to block until the values becomes available. While this approach does not eliminate blocking, it transfer the responsibility of blocking from renderPage method to the caller thread (Main Thread).
Future Polling Example:

def futurePooling: Unit = {
    val content = Future { scala.io.Source.fromFile("/home/harmeet/sample").mkString }
    println("Start reading the file asynchronously")
    println(s"Future status: ${content.isCompleted}")
    Thread.sleep(250)
    println(s"Future status: ${content.isCompleted}")
    println(s"Future value: ${content.value}")
}

In example we are using method which are performing polling for us and after check its completion status, we are fetching the values using method.

def isCompleted: Boolean
def value: Option[Try[T]]

Note: Polling is like calling your potentials employer every 5 minutes to ask if you’re hired
The conceptual diagram for our pooling mechanism as below:

Pooling Example Flow

Scala Futures have allow additional ways for handling future values and avoid blocking. For more information please click on link

References:
  1. Java api’s docs.