JVM Internal

A Java virtual machine (JVM) is a virtual machine that can execute Java bytecode . In the name itself it same its one time of virtual machine . It is the code execution component of the Java software platform

if you understand JVM, you will understand Java more, and will be able to solve the problems which seem to be so simple but unsolvable

Thus, in this article I will explain how JVM works, its structure, how it executes Java bytecode, the order of execution, examples of common mistakes and their solutions, as well as the new features in Java SE 7 Edition.

 Virtual Machine

The JRE is composed of the Java API and the JVM. The role of the JVM is to read the Java application through the Class Loader and execute it along with the Java API. A virtual machine (VM) is a software implementation of a machine (i.e. a computer) that executes programs like a physical machine. Originally, Java was designed to run based on a virtual machine separated from a physical machine for implementing WORA (Write Once Run Anywhere. although this goal has been mostly forgotten. Therefore, the JVM runs on all kinds of hardware to execute the Java Bytecode without changing the Java execution code.

The features of JVM are as follows:

• Stack-based virtual machine: The most popular computer architectures such as Intel x86 Architecture and ARM Architecture run based on a register. However, JVM runs based on a stack.
• Symbolic reference: All types (class and interface) except for primitive data types are referred to through symbolic reference, instead of through explicit memory address-based reference. 
• Garbage collection: A class instance is explicitly created by the user code and automatically destroyed by garbage collection.
• Guarantees platform independence by clearly defining the primitive data type: A traditional language such as C/C++ has different int type size according to the platform. The JVM clearly defines the primitive data type to maintain its compatibility and guarantee platform independence.  << THIS IS VERY IMPORTANT POINT… WHICH IS CLEAR SEPARATION OF Platform independence>>

Sun Microsystems developed Java. However, any vendor can develop and provide a JVM by following the Java Virtual Machine Specification. For this reason, there are various JVMs, including Oracle Hotspot JVM and IBM JVM. The Dalvik VM in Google's Android operating system is a kind of JVM, though it does not follow the Java Virtual Machine Specification. Unlike Java VMs, which are stack machines, the Dalvik VM is a register-based architecture. Java bytecode is also converted into an register-based instruction set used by the Dalvik VM .

Java bytecode

To implement WORA, the JVM uses Java bytecode, a middle-language between Java (user language) and the machine language. This Java bytecode is the smallest unit that deploys the Java code. Before explaining the Java bytecode, let's take a look at it. This case is a summary of a real example that has occurred in development process.

Java Bytecode is the essential element of JVM The JVM is an emulator that emulates the Java Bytecode. Java compiler does not directly convert high-level language such as C/C++ to the machine language (direct CPU instruction); it converts the Java language that the developer understands to the Java Bytecode that the JVM understands. Since Java bytecode has no platform-dependent code, it is executable on the hardware where the JVM (accurately, the JRE of the same profile) has been installed, even when the CPU or OS is different (a class file developed and compiled on the Windows PC can be executed on the Linux machine without additional change.) The size of the compiled code is almost identical to the size of the source code, making it easy to transfer and execute the compiled code via  the network.

The class file itself is a binary file that cannot be understood by a human. To manage this file, JVM vendors provide javap, the disassembler. The result of using javap is called Java assembly. In the above case, the Java assembly below is obtained by disassembling the UserService.add() method of the application code with the javap -c option.


The first 16 bytes of the UserService.class file disassembled earlier are shown as follows in the Hex Editor.
ca fe ba be 00 00 00 32 00 28 07 00 02 01 00 1b

There are 10 basic sections to the Java Class File structure:

• Magic Number: 0xCAFEBABE
• Version of Class File Format: the minor and major versions of the class file
• Constant Pool: Pool of constants for the class
• Access Flags: for example whether the class is abstract, static, etc.
• This Class: The name of the current class
• Super Class: The name of the super class
• Interfaces: Any interfaces in the class
• Fields: Any fields in the class
• Methods: Any methods in the class
• Attributes: Any attributes of the class (for example the name of the sourcefile, etc.)

There is a handy mnemonic for remembering these 10: My Very Cute Animal Turns Savage In Full Moon Areas.
Magic, Version, Constant, Access, This, Super, Interfaces, Fields, Methods, Attributes (MVCATSIFMA)
major version number of the class file format being used.
J2SE 7 = 51 (0x33 hex),
J2SE 6.0 = 50 (0x32 hex),
J2SE 5.0 = 49 (0x31 hex),
"We used to go to lunch at a place called St Michael's Alley. According to local legend, in the deep dark past, the Grateful Dead used to perform there before they made it big. It was a pretty funky place that was definitely a Grateful Dead Kinda Place. When Jerry died, they even put up a little Buddhist-esque shrine. When we used to go there, we referred to the place as Cafe Dead. Somewhere along the line it was noticed that this was a HEX number. I was re-vamping some file format code and needed a couple of magic numbers: one for the persistent object file, and one for classes. I used CAFEDEAD for the object file format, and in gripping for 4 character hex words that fit after "CAFE" (it seemed to be a good theme) I hit on BABE and decided to use it. At that time, it didn't seem terribly important or destined to go anywhere but the trash-can of history. So CAFEBABE became the class file format, and CAFEDEAD was the persistent object format. But the persistent object facility went away, and along with it went the use of CAFEDEAD - it was eventually replaced by RMI."
 To prepare for such cases, the Java class loader is verified through a very strict and tight process. The JVM specifications explicitly detail the process.

A class loader loads the compiled Java Bytecode to the Runtime Data Areas, and the execution engine executes the Java Bytecode.

Class Loader : The Bootstrap Class Loader is the parent of all class loaders.

• Bootstrap class loader: This is created when running the JVM. It loads Java APIs, including object classes. Unlike other class loaders, it is implemented in native code instead of Java.
• Extension class loader: It loads the extension classes excluding the basic Java APIs. It also loads various security extension functions.
• System class loader: If the bootstrap class loader and the extension class loader load the JVM components, the system class loader loads the application classes. It loads the class in the $CLASSPATH specified by the user.
• User-defined class loader: This is a class loader that an application user directly creates on the code.

Abstract Factory Design Pattern

Abstract Factory ( Creational Design Pattern )

The abstract factory pattern is a software creational design pattern that provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes.  or in similar way we can say as 
The Abstract Factory design pattern (part of the Gang of Four) falls under the Creational design pattern category and it provides a way to encapsulate a group of factories that have a common link without highlighting their concrete classes. 
This is all about a factory creating various objects at run time based on user demand. The client remains completely unaware (decoupled) on which concrete products it gets from each of these individual factories and the client is only able to access a simplified interface.

The essence of the Abstract Factory Pattern is to "Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

As intent of any Creational design pattern is to avoid using of "new" operator 

Abstract Factory patterns works around a super-factory which creates other factories. This factory is also called as Factory of factories. In Abstract Factory pattern an interface is responsible for creating a factory of related objects, without explicitly specifying their classes. This pattern is one level of abstraction higher than factory pattern.

 

As there is a word ‘abstract’ in the pattern name don’t mistake and confuse it with java ‘abstract’ keyword .  It considered as another layer of abstraction over factory pattern.

 

e.g. In Java while doing XML work with DOM Parser , we have used DocumentBuilderFactory   class which is an example abstract factory design pattern because it returns a factory called DocumentBuilder which then used to create Document.

//Example of Abstract Factory and Factory design pattern  in Java
DocumentBuilderFactory abstractFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder factory = abstractFactory.newDocumentBuilder();
Document doc = factory.parse(stocks)

In this example DocumentBuilderFactory (Abstract Factory) creates DocumentBuilder (Factory) which creates Documents (Products).

In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interfaces to create the concrete objects that are part of the theme. The client does not know (or care) which concrete objects it gets from each of these internal factories, since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from their general usage and relies on object composition, as object creation is implemented in methods exposed in the factory interface

Example : The best example will be configuring Database connection factory which hide underline Database type. We can configure Oracle, DB2 or Sybase Connection Factory in application.

    1)  java.util.Calendar#getInstance()
    2) java.text.NumberFormat#getInstance()

Running Example

1)  Let's assume we are startup company who want to manufacture different types of cars .  We have below 3 types of cars in the production unit.

We have created enum of those types

public enum CarType {

      SMALL, SEDAN, LUXURY

}

We have different locations all over the globe where we want to open franchise

public enum Location {

    INDIA , USA , DEFAULT , EUROPE , ASIA

}

Let's define abstract class for all cars and then we can construct each type as per specific requirement .

public abstract class Car {

      private CarType model = null;

      private Location location = null;

     

      public Car(CarType model, Location location){

             this.model = model;

             this.location = location;

             }

             

      protected abstract void construct();

      public CarType getModel() {

            return model;

      }

      public void setModel(CarType model) {

            this.model = model;

      }

      public Location getLocation() {

            return location;

      }

      public void setLocation(Location location) {

            this.location = location;

      }

     

      @Override

      public String toString() {

            return "Model- "+model + " built in "+location;

           

      }

}

OK , so now we have abstract class where we have taken help from mechanical engineer team and define basic parameters . 

Now we are standing in production unit where we  can actually "construct" car as per design approved by team. 

Here we go with Small Car where we are just putting system out to display we are constructing car. 

public class SmallCar extends Car{

     

      public SmallCar(Location location){

            super(CarType.SMALL, location);

      }

      @Override

      protected void construct() {

            System.out.println("Building SMALL car");

           

      }

}

Now we have some experience of constructing small car , now lets do some thing more :)

public class SedanCar extends Car{

     

      public SedanCar(Location location){

            super(CarType.SEDAN, location);

      }

      @Override

      protected void construct() {

            System.out.println("Building SEDAN car");

           

      }

}

Let's construct luxury car

public class LuxuryCar extends Car{

     

      public LuxuryCar(Location location){

            super(CarType.LUXURY, location);

      }

      @Override

      protected void construct() {

            System.out.println("Building luxury car");

           

      }

}

We have all 3 model's developed .  Now we can go for constructing the Factory for those 

1)  public class DefaultCarFactory {

            Car car = null;

      public static Car buildCar(CarType model){

            switch (model){

            case SMALL:

                  car = new SmallCar(Location.DEFAULT);   

                  break;

            case SEDAN:

                  car = new SedanCar(Location.DEFAULT);      

                  break;

            case LUXURY:

                  car = new LuxuryCar(Location.DEFAULT);    

                  break;     

            }

            return car;

      } }

2)  public class AsiaCarFactory {

            Car car = null;

      public static Car buildCar(CarType model){

            switch (model){

            case SMALL:

                  car = new SmallCar(Location.ASIA);        break;

            case SEDAN:

                  car = new SedanCar(Location.ASIA);        break;

            case LUXURY:

                  car = new LuxuryCar(Location.ASIA);       break;     

           

            }

            return car;

      }}

3)  public class USACarFactory {

            Car car = null;

      public static Car buildCar(CarType model){

            switch (model){

            case SMALL:

                  car = new SmallCar(Location.USA);   break;

            case SEDAN:

                  car = new SedanCar(Location.USA);   break;

            case LUXURY:

                  car = new LuxuryCar(Location.USA); break;     

            }

            return car;

      }

}

Here the heart of our factory is CarFactory

 public class CarFactory {

      private CarFactory() { }

     

      public static Car buildCar(CarType type)

      {

            Car car = null;

            Location location = Location.ASIA;

            switch(location)

            {

            case USA:

                  car = USACarFactory.buildCar(type); break;

                 

            case ASIA:

                   car = AsiaCarFactory.buildCar(type);  break;

                   

            case DEFAULT:

                  car = DefaultCarFactory.buildCar(type); break;

            }

            return car;

      }

}

 

All things done , now lets give franchises and earn some money :) 

public class TestFactoryPattern {

     /**

      * @param args

      */

     public static void main(String[] args) {

          System.out.println(CarFactory.buildCar(CarType.SMALL));

          System.out.println(CarFactory.buildCar(CarType.SEDAN));

          System.out.println(CarFactory.buildCar(CarType.LUXURY));

     }

}

Abstract Factories are great for supporting multiple platforms while keeping your code-base unified. Suppose you have a large Qt or GTK+ or .NET/Mono program that you want to run on Windows, Linux, and OSX. But you have a feature that is implemented in a different way on each platform (perhaps via the kernel32 API or a POSIX feature).

public abstract class Feature
{
    public abstract int PlatformSpecificValue { get; }

    public static Feature PlatformFeature
    {
        get
        {
            string platform;
            // do platform detection here
            if (platform == "Win32")
                return new Win32Feature();
            if (platform == "POSIX")
                return new POSIXFeature();
        }
    }

    // platform overrides omitted
}

With this Abstract Factory, your UI doesn't need to know anything about the current platform.

Feature feature = Feature.PlatformFeature;
Console.WriteLine(feature.PlatformSpecificValue);

 
Alternative approach for design pattern
1)  Sometimes creational patterns are competitors: there are cases when either Prototype or Abstract Factory could be used profitably. At other times they are complementary: Abstract Factory might store a set of Prototypes from which to clone and return product objects, Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementation.

2) Abstract Factory can be used as an alternative to Façade pattern to hide platform specific classes
3) AbstractFactory class declares only an interface for creating the products. The actual creation is the task of the ConcreteProduct classes, where a good approach is applying the Factory Method design pattern for each product of the family.
4)  Abstract Factory classes are often implemented with Factory Methods, but they can also be implemented using Prototype.

 

Most Discussion question in universe of design pattern :) 

Difference between Abstract Factory and Factory Method pattern:

• Factory Method pattern exposes a method to the client for creating the object whereas in case of Abstract Factory they expose a family of related objects which may consist of these Factory methods.
• Designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.
• Factory Method pattern hides the construction of single object where as abstract factory method hides the construction of a family of related objects. Abstract factories are usually implemented using (a set of) factory methods.

Keep in Mind 

progress