The process of destroying unused/unreferenced objects are called garbage collection. Java garbage collection is the process by which Java programs performs automatic memory management.

When Java programs run on the JVM, objects are created on the heap. When the object is no longer required, garbage collector find those unused objects and remove them to free up memory for reuse.

How Garbage Collection work?

Java Garbage collection is an automatic process, we don’t need to explicitly mark objects for deletion. Garbage collection implementation lives in the JVM. We can only request JVM for garbage collection, by using System.gc() and Runtime.getRunTime.gc(), but we can’t force it.

Different JVM’s have their own way of garbage collection implementation, Oracle’s HotSpot is the most common JVM which offers the robust and mature set of garbage collection options. HotSpot has multiple garbage collectors that are optimized for various use cases, but all follow the same basic principle.

In the first step, all the live objects are tracked and marked as alive. Everything else is eligible for garbage collection.

In the second step, eligible objects for garbage collection are deleted from the heap. Optionally memory can be compacted, so that remaining objects are in a contiguous block at the start of the heap. The memory compacting process makes it easier to allocate memory to new objects sequentially after the block of memory allocated to existing objects.

All objects are allocated on heap memory are managed by JVM. As long as the object being referenced, the JVM considers it alive.

All HotSpot garbage collectors implement Generational Garbage Collection strategy, which categorizes objects by their age. As per the Generational Garbage collection strategy, it believes that most objects are short-lived and are eligible for garbage collection as soon as they are created.

The heap is divided into three sections:

Garbage Collection in Java

• Young Generation:
  Newly created objects start in Young generation. The young generation is further subdivided into Eden and two survivors (S1, S2) spaces. Eden is the space where are the newly created objects start and moved to Survivor space after one GC cycle. When objects are garbage collected from Young generation space are called minor GC event.
• Old Generation:
  Objects that are long-lived are moved from Young Generation to Old Generation. When objects from Old generation are garbage collected are major GC event.
• Permanent Generation (PermGen):
  Metadata (classes and methods) are stored in Permanent Generation. Classes that are no longer required may be garbage collected from Permanent Generation.

In Java 8, PermGen is replaced by  Metaspace. Metaspace now uses native memory for the representation of class metadata. It is not mandatory now to define PermSize and MaxPermSize. So, when memory usage increases you will not get the OutOfMemoryError, reserve native memory is increased to full-fill the memory usage. To know more about Metaspace, read this article.

During a full garbage collection event, unused objects in all generations are garbage collected.

Garbage Collection Roots (GC Roots):

GC Roots are basically stack variable/pointers that hold the reference to objects in Heap and accessible directly outside from the heap. Every object must have one or more root objects, as long as the application can reach those roots, the whole object tree is reachable.

There is four kind of GC roots in Java:

• Local variables: They are not a real object virtual reference and kept alive on the stack of the thread. For all intents and purposes, local variables are GC Roots.
• Active Java Thread: They are always live objects and are considered GC roots, this is also important for thread local variables.
• Static Variables: They are referenced by their classes, which makes GC roots. Classes themselves can be garbage collected which also removes all referenced static variables.
• JNI References: These are the java objects which gets created by native code as part of the  JNI call. Objects created are treated specially because the JVM does not know if it is being referenced by native code or not.

A simple java application has the following GC roots:

1. The local variable in the main method.
2. The main thread
3. Static variables of the main class.

Mark and Sweep Algorithm:

To determine which objects are no longer in use, the JVM intermittently runs mark and sweep algorithm. It is a 2 step process:

1. The algorithm traverses all the object references, starting with the GC roots and marks every object found alive.
2. Heap memory which is not occupied by marked objects is reclaimed and marked as free.

HotSpot JVM has four garbage collectors:

• Serial: Garbage collection events are performed serially in one thread. Memory compaction is performed after each garbage collection event.
• Parallel: Multiple threads are used for minor garbage collection. A single thread is used for major garbage collections and Old Generation memory compaction. Alternatively Parallel Old variant uses multiple threads for major garbage collection and Old Generation Compaction.
• Concurrent Mark and Sweep (CMS): Multiple threads are used for minor garbage collection using the same algorithm as parallel. Major garbage collection is also multi-threaded like Parallel Old, but CMS runs concurrently with the application. This means that garbage collection is not explicitly stopping the application threads to perform GC. No compaction is performed.
• G1 (Garbage first): This newest garbage collector is intended as a replacement for CMS. It is parallel and concurrent like CMS. The Garbage-First (G1) collector is a server-style garbage collector, targeted for multi-processor machines with large memories. It meets garbage collection (GC) pause time goals with a high probability while achieving high throughput.

The post Garbage Collection in Java appeared first on Manish Sanger.

Why Spring Boot?
In a traditional monolithic approach for developing web/RESTful application, a WAR is created and deployed on a web server like: Tomcat, Jboss, IBM WebSphere etc.
From a microservices point of view, we need to develop services as executable, self-contained JAR files with an embedded HTTP listener.

Spring Boot features:

1. 1. Self-Contained web server: We can easily embed HTTP listeners for the web application. We can easily create a self-contained HTTP server using embedded tomcat, jetty etc.
   2. Standalone application: We can create a standalone executable application. It has SpringApplication class which provides the convenient way to bootstrap a spring application which can be started from the main method just by calling static method SpringApplication.run().
   3. Externalized configuration: It allows us to externalize the configuration so that we can work with the same application in various environments. We can use YAML files to externalize the configuration.
   4. YAML Support: It provides support for YAML configuration by default.
   5. Application Properties: It provides a rich set of application properties, for example: server-port, application-name and many more.
   6. Actuator: It provides production readiness by actuators such as metrics and health check.
   7. Type-safe configuration: It also provides a strong type-safe way to handle the configuration by allowing the developer to create a bean and populating it with the property value from a configuration file using annotation.
   8. Logging: It provides out of the box logging for all internal logging. Logback is provided by default without any additional configuration, which can be altered if needed.
   9. Security: It provides the feature of enabling the basic security by using the spring boot started security. It enables the basic security by default, which can be further enhanced to utilize the full strength of Spring security.

Related Articles:
Getting started with Spring Boot, Create your first REST API application

The post Introduction to Spring Boot appeared first on Manish Sanger.

Prerequisite:

1. Maven 3.X
2. Java 1.8/1.7

Getting Started – Step by Step guide

The best way to bootstrap your Spring Boot projects is to use Spring Initializr

It allows you to bootstrap various type of Spring Boot application from a simple web UI. You can select various available libraries from UI as per your requirement.

There are various option to generate, you can choose from Maven/Gradle project, with Java/Kotlin/Groovy and appropriate spring boot version. We will be using Maven, Java and Spring Boot 2.0.0 here.

Define group, artifact, name & description of the application on the UI.

Click on “Switch to the full version” at the bottom left to see the list all available library options to be included in the project. For this article, I have selected the following as this is just a basic article to get started with Spring Boot.

Web:
-Web
-Jersey(JAX-RS)

Ops:
-Actuator

Click on “Generate Project” button at the bottom of the screen to download bootstrap project with Spring Boot.

Spring Initializr- Spring Boot, bootstrap your first REST API application

Import the project in your favorite IDE – Eclipse, IntelliJ Idea, STS or any other. I am using IntelliJ Idea on Mac OSX.

Project Structure will look like as follows:

Spring boot – REST API project structure

Here is pom.xml dependencies, downloaded from Spring Initializr.

Spring Boot REST API – maven dependencies

spring-boot-starter-web – Starter for building web, including RESTful, applications using Spring MVC. Uses Tomcat as the default embedded container.

spring-boot-starter-actuator – Actuator provides production readiness of the application by monitoring our application, gathering metrics, understanding traffic, state of database etc. Will see actuator in more details in my next article.

Here is the Application file, which has the main method to run the Spring Boot application to make it executable:

@SpringBootApplication

public class SpringbootdemoApplication {

public static void main(String[] args) {

SpringApplication.run(SpringbootdemoApplication.class, args);

}

}

Create a Rest Controller, to create your first REST endpoint. Here is the code:

@RestController

@RequestMapping(value = "/", produces = MediaType.APPLICATION_JSON_VALUE)

public class HelloController {

@RequestMapping("/")

public ResponseEntity<Response<List>> index() {

HttpHeaders headers = new HttpHeaders();

List listData = new ArrayList<>();

listData.add("This is a First REST API with Spring boot");

listData.add("Test2");
return new ResponseEntity<>(new Response<>(HttpStatus.OK.value(),

"First Spring Boot REST API is working", listData), HttpStatus.OK);

}

}

I create a class named Response to convert data to JSON and define a proper response format. This is not required, but I always prefer to have a class like this as it easy to format/standardize your response and pass HTTP status code &message to variety of API consumers.

@JsonInclude(value = Include.NON_EMPTY)

public class Response {

private int status;

private String message;

private T data;
public Response(int status, String message, T data) {

super();

this.status = status;

this.message = message;

this.data = data;

}
public Response() {

super();

}
public int getStatus() {

return status;

}
public String getMessage() {

return message;

}
public T getData() {

return data;

}

}

You can also use lombok project (https://projectlombok.org/), if you don’t want to write/generate getters & setters.

That’s it, now we are ready to launch our first sample Spring Boot REST API project.

Go to Terminal and use the following commands to run the application.

mvn clean install

java -jar springbootdemo-0.0.1-SNAPSHOT.jar

You can also run from your IDE. I am using IntelliJ Idea, so I can run it from IDE itself.

Once the run is complete, you can access it on http://localhost:8080/ or via postman. We haven’t made any configuration changes to it will run on localhost and default port 8080.

Here is the response:

Spring Boot – REST API Response

You can access Actuator Health and Info as follows:
http://localhost:8080/actuator/health
http://localhost:8080/actuator/info

The post Getting started with Spring Boot, Create your first REST API application appeared first on Manish Sanger.

Many organizations such as Netflix and Amazon used this technique to functionally partition their applications into smaller atomic units.

Micro-services originated from the idea of hexagonal architecture. Hexagonal architecture is also known as the Ports and Adapters Pattern.
Hexagonal Architecture >>

Monolithic Application

Let’s take an example of an E-commerce application. In a typical monolithic architecture, all modules are part of the same project/package and are connected with single database technology as shown in the architecture above. Here are some of the problem, which developer and business were facing with Monolithic architecture over the period of time:

1. In older and large applications, codebase increased over the period of time and it takes ages to build and deploy.
2. There is a technology constraint with the application, new features have to be developed with old technology stack, or it requires a huge amount of effort to upgrade the version or using latest tools and technologies available.
3. Each module is tightly coupled with other modules, so if you change one module it will impact the other module also, so maintaining the monolithic applications are more error-prone.
4. When you make a change in any module, whole application has to be built and deployed again.
5. You can’t scale only one section of the application. For example, in an E-commerce application, search and browse catalog usually have the highest load, in the monolithic approach we can’t only scale these two services only, we have to scale the whole application on separate server instances behind a load balancer.

In traditional monolithic application, we build a .war or .ear and deploy it on an application server like Tomcat, JBoss, WebLogic, WebSphere etc. In micro-service architecture, each micro-service will be built as a jar, embedded with all the dependencies and run as a standalone Java process.
Micro-services may also have their own containers for execution. Container technology like Docker is an ideal choice for micro-services deployment.

Microservices Architecture

Benefits of using micro-services:

1. Can use different architecture, technology and version of the technology for each micro-service.
2. Enabling experimentation and innovation. for example, recommendation engine, where we keep changing the recommendation algorithm.
3. Elastically and selectively scalable, we can select only the selected service where application receives the highest load. For example: Search and Catalog section of the e-commerce application.
4. This enables building up an organic system, where we keep adding the feature in an agile way over the period of time without impacting the existing system.
5. This helps in reduction of technology debt, we can change/upgrade technologies with much lesser effort/impact as compare to monolithic.
6. It supporting event-driven architecture, for example: In e-commerce when an order is received various service has to be invoked like: save order, update inventory, send email/SMS/push notification, data analysis, delivery etc.
7. Micro-service are the key enabler for DevOps. It advocates automating as much as possible, for example, continuous integration – testing, automatic infrastructure provisioning, automatic build, automatic deployment etc.

The post Microservices – An Introduction appeared first on Manish Sanger.

Java Exception Hierarchy

As shown in the exception hierarchy, a Throwable class is a superclass of all errors and exceptions in Java. Objects those are instances of Throwable or one of its subclasses are thrown by JVM or by Java throw statement.

Error:
An Error is a subclass of Throwable that represents serious errors that can’t be handled. A method is not required to declare throws clause for Error or any of its subclasses for the errors thrown during execution of the method but not caught.

Error and its subclasses are unchecked exceptions.
Here are the examples of errors: OutOfMemoryError, StackOverflowError, AssertionError, IOError, NoClassDefFoundError etc.

Exception:
Exception is a subclass of Throwable. Exception and its subclasses represent the problems from which a program can recover and should be handled by the application.
Exception has two sub type:

1. RunTimeException or Unchecked Exception:
The classes that extends RunTimeException are called unchecked Exception. An unchecked exception occurs at run-time, it can’t be checked at compile time, an application should handle these exceptions. For example: NullPointerException, ArithmeticException, IllegalArgumentException, IndexOutOfBoundException etc.

2. Checked Exception:
The classes that extends Throwable class except RunTimeExpception and Error are called Checked Exception. Checked exception are checked at compile time and application should handle these exceptions. For example: IOException, SQLException, FileNotFoundException, ClassNotFoundException, NoSuchMethodException etc.

User-defined custom exception:
We can also create our own exception. Here are few rules:
1. All exception must be a child of Throwable.
2. To create a RuntimeException, we need to extend the RunTimeException class.
3. To create the checked exception, we need to extend the Exception class.

Reference:
https://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html
https://docs.oracle.com/javase/8/docs/api/java/lang/Error.html

The post Java Exception Hierarchy appeared first on Manish Sanger.

Generics in Java provide type checking at compile time and it has nothing to do at runtime. Java compiler uses Type Erasure feature to remove all generics type checking code (replace it with bound or Object if the type parameters are unbounded) in bytecode, insert type casting if necessary and generate bridge methods to preserve polymorphism in extended generic types.

Here is an example of generic a class:

class TypeErasureExample {

private T t;

public TypeErasureExample(T t) {

this.t = t;

}
public T getT() {

return t;

}

}

After compilation the type will be replaced with String as follows:

class TypeErasureExample {

private String t;

public TypeErasureExample(String t) {

this.t = t;

}
public String getT() {

return t;

}

}

Type erasure at class or class variable level:
At the class level, type parameters on the class are removed at compile time and replaced with its first bound or Object if the type parameter is unbound.
Here are few examples:
Type erasure when type parameter is unbound:

class TypeErasureUnboundExample {

private T t;

public TypeErasureUnboundExample(T t) {

this.t = t;

}
public T getT() {

return t;

}

}

After compilation the type will be replace with Object (because type parameter is unbound) as follows:

class TypeErasureUnboundExample {

private Object t;

public TypeErasureUnboundExample(Obhect t) {

this.t = t;

}
public Object getT() {

return t;

}

}

Type erasure when type parameter is bound:

class TypeErasureExample {

private T t;

public TypeErasureExample(T t) {

this.t = t;

}
public T getT() {

return t;

}

}

After compilation the type will be replaced with String (with first bound) as follows:

class TypeErasureExample {

private String t;

public TypeErasureExample(String t) {

this.t = t;

}
public String getT() {

return t;

}

}

For example:
If type parameter is unbounded:

public static  void genericMethod(T t){

        System.out.println(t);

    }

Will be converted to following at compile time:

public static void genericMethod(Object t){

        System.out.println(t);

    }

If type parameter is bounded:

public static  void genericMethod(T t){

        System.out.println(t);

    }

Will be converted to following at compile time:

public static void genericMethod(String t){

        System.out.println(t);

    }

The post Type Erasure – Java Generics appeared first on Manish Sanger.

Unbounded wildcard
When we want our generic type to be working with all types, an unbounded wildcard can be used.
For example:

class UnboundWildcard {

    public static void UnboundWildcardPrint(List list) {

        list.forEach(listElement->{

            System.out.println(listElement);

        });

    }

    public static void main(String[] args) {

        List list = new ArrayList<>();

        list.add("A");

        list.add("B");

        list.add("C");

        UnboundWildcardPrint(list);

        List numbers = new ArrayList<>();

        numbers.add(10);

        numbers.add(50);

        numbers.add(100);

        UnboundWildcardPrint(numbers);

    }

}

In the above example list parameter is provided as List and List, it can be of any other type of Object List argument to UnboundWildcardPrint method.
Unbounded wildcard is equivalent to .

Upper Bounded wildcard
This is useful when we want to relax the restriction on the type of parameter in a method. For example, we want to write a method, that works with List, List, List, and List. We can do this by using an upper bound wildcard as follows:

Public static void sum(List)

Lower Bound wildcard:
This is useful when we want to restrict the type of parameter in a method to it’s lower bound and it’s super class.
For example:

public static void sumIntegers(List list)

In the above example, we can only pass Integer or Number (Super class of Integer). We can’t pass Double or Long, as they aren’t the Super class of Integer.

The post Wildcard – Java Generics appeared first on Manish Sanger.

Here is an example of ArrayList without using generics:

List names = new ArrayList();

names.add("Manish");

String name = (String) names.get(0); //Type casting when retrieving the element from the array list

Integer number = (Integer) names.get(0); //Run-time error, ClassCastException will be thrown.

When we use the ArrayList without generics, will have to type cast when we retrieve the element from the ArrayList, as the program doesn’t know the type of element stored in ArrayList. Also, when we try to type cast the element in the wrong way as I did in the code above, trying to type cast the element to Integer it will throw run-time ClassCastException error. Without generics, we only get the errors at the run-time not at compile time.

We can rewrite the code using generics as follows:

List names = new ArrayList();

names.add("Manish");

String name = names.get(0); //No type casting is required.

Creating custom Java generic Class:
We can create our own generic class. A generic type is a class or interface that is parameterized over types, we use angle bracket (<>) to specify the type parameter.
Note: Type argument can’t be of a primitive type.

public class GenericExample {

    private T t;

    public T getT() {

        return t;

    }

    public void setT(T t) {

        this.t = t;

    }

}

class GenericTest{

    public static void main(String[] args) {

        //Instance with String type

        GenericExample genericExample = new GenericExample<>();

        genericExample.setT("Test");
        //Instance with Integer type

        GenericExample genericExample1 = new GenericExample<>();

        genericExample1.setT(100);
        //Type argument can't be primitive type.

    }

}

Class with multiple type parameters:

public class GenericExample {

    private T t;

    private U u;

    public GenericExample(T t, U u) {

        this.t = t;

        this.u = u;

    }

}
class GenericTest{

    public static void main(String[] args) {

        //Instance with String type

        GenericExample genericExample = new GenericExample<>("Test", 100);

    }

}

Generic Method
We can also create the generic method or constructor, no need to parameterize the whole class.

class GenericMethodTest{

    static  void genericMethod(T t){

        System.out.println(t);

    }

    public static void main(String[] args) {

        GenericMethodTest.genericMethod("Test");

        GenericMethodTest.genericMethod("Test 2"); //Using type interface

    }

}

In the above code, we can specify the type when calling the method or can just call like a normal method without specifying any type, JVM will do it for you. This feature is called type interface.

Java generics bounded type parameters:
If we want to restrict the type of objects which can be used as parametrized type:

class GenericBound {

    private T t;

    public GenericBound(T t) {

        this.t = t;

    }

}

Java generic type naming convention (Best practices)
As per the Java best practices, type parameter should be single and uppercase letters. Following are the commonly used type parameters:

• T – Type
• E – Element (Used extensively in collection framework)
• N – Number
• K – Key
• V – Value
• S,U,V etc. – 2nd, 3rd, 4th types

The post Java Generics appeared first on Manish Sanger.

Prior to Java 7, there was no auto resource management, we open the resource in a try block and close the resource in finally block. For example:

try{

//open resources

}catch(IOException){

//Exception handling

}finally{

//close resource

}

In the above approach there were few drawbacks:

1. It causes memory leaks and performance issue if the developer forgot to close the resource.
2. Finally block will always be executed, it doesn’t matter if the exception is thrown from the try block. It means, it tries to close the resource in finally block, even if it doesn’t exist which again cause an exception to be thrown from finally block.
3. Exception thrown from finally block will be propagated up the call stack, though exception from try block is more relevant.

try-with-resource
In Java 7, a new approach called “try-with-resources” is introduced for auto resource management. In this when try block finishes, it automatically closes the resource.

Here is an example for try-with-resource construct:

private static void readFile() throws IOException {

try(FileInputStream input = new FileInputStream("file.txt")) {

int data = input.read();

while(data != -1){

System.out.print((char) data);

data = input.read();

}

}

}

try-with-resource using multiple resources
We can use multiple resources in try-with-resource block, it will automatically close both the resources when program finish executing try block.

private static void readFile() throws IOException {

try(  FileInputStream input = new FileInputStream("file.txt");

BufferedInputStream bufferedInput = new BufferedInputStream(input)

) {

int data = bufferedInput.read();

while(data != -1){

System.out.print((char) data);

data = bufferedInput.read();

}

}

}

The resources are closed in reverse order of they are declared inside the try. BufferedInputStream will be closed first, then FileInputStream.
 
AutoCloseable Custom implementation
Java 7 has introduced an interface java.lang.AutoCloseable. To use any resource in try-with-resource block, it must implement the AutoCloseable interface. We can also implement java.lang.AutoCloseable interface in our own classes and use them with the try-with-resources construct.
AutoCloseable interface only has one method class close(). Here is the AutoCloseable interface:

public interface AutoCloseable {

public void close() throws Exception;

}

 
Exception handling with try-with-resource:
If one or more exceptions are thrown by try block in try-with-resources, the exceptions thrown are suppressed exception.
Java added an constructor and two methods in Throwable class to deal with suppressed exceptions. We can get these exceptions by using the getSuppress() method of Throwable class.

Advantages of using try-with-resource construct:

1. Auto resource management.
2. More readable code.
3. No need of finally block just to close the resource.
4. Meaning & relevant exceptions.

The post Java Try with Resources appeared first on Manish Sanger.