Writing Soon
While coding in any programming language we always require some predefined types which we can use to write the code and every programming language provides these types in its way e.g. Java provides primitive types (int, long, char float etc) and reference types (custom types like Object, String, Thread).

For string manipulation, Java provides a class java.lang.String which gives us a way to create string objects and provides different behaviors to operate on those objects e.g. replace(), length()


String name = "Naresh";
System.out.print(name.length());
System.out.print(name.isEmpty());

Whenever we talk about String class in Java we say it is immutable in nature and all string literals are stored in String Constant Pool (SCP).

Prior to Java 7 String Constant Pool belongs to Permanent Generation area of heap which means Garbage Collector will not touch it in normal scenarios. But from Java 7 onwards string constant pool is not part of Perm Gen but live with out in heap which means now unused String objects will get garbage collected.

And in order to become a good developer, we should always know why these kinds of design decisions were taken. I mean, we should know why String is immutable or why string objects stored in SCP.

In Why String is Stored in String Constant Pool article, I have discussed why string objects are stored in a separate memory area called constant pool and in this article, I will discuss why String class was made immutable.

String is Effective Immutable not Completely Immutable

In normal scenarios, String objects are immutable and can't be modified but we can modify them by using Java reflection API. Every string object holds a char[] array as a private variable which actually holds every character from our string.

why-string-is-immutable-and-final-in-java

Due to the private nature of the char[] array, we cannot access it from outside of string object and none of the string methods modifies it.

But we can access this char[] array via reflection and then modify it, And that's why instead of calling String immutable we can call it Effective Immutable.

String string = "Naresh";

Class<String> type = String.class;
Field field = type.getDeclaredField("value");
field.setAccessible(true);

char[] value = (char[]) field.get(string);
value[0] = 'M'; // No `string` variable becomes `Maresh`


Why String is Final

As discussed in How to Create an Immutable Class in Java, in order to make a class immutable we need to make sure no one extends our class and destroy its immutability.

So String is made final to not allow others to extend it and destroy its immutability.

Why String is Immutable

However we can not be sure of what was Java designers actually thinking while designing String but we can only conclude these reasons based on the advantages we get out of string immutability, Some of which are as follows.

1. Existence of String Constant Pool

As discussed in Why String is Stored in String Constant Pool, In order provide a business functionality every application creates too many string objects and in order to save JVM from first creating lots of string objects and then garbage collecting them. JVM stores all string objects in a separate memory area called String constant pool and reuses objects from that cached pool.

Whenever we create a string literal JVM first sees if that literal is already present in constant pool or not and if it is there, the new variable will start pointing to the same object in SCP this process is called String Interning.

String a = "Naresh";
String b = "Naresh";
String c = "Naresh";

In above example string object with value Naresh will get created in SCP only once and all variables a, b, c will point to the same object but what if we try to make change in a e.g. a.replace("a", "").

Ideally a should have value Nresh but b, c should remain unchanged because as the end user we are making change in a only. And as a developer we know a, b, c all are pointing the same object so if we make a change in a, others should also reflect the change.

string-constant-pool-in-java

But String's immutability saves us from this scenario and due to which object Naresh will never change. So when we make any change in a, JVM will create a new object assign it to a, and then make the change to that object instead of changing object Naresh.

So having a string pool is only possible because of String's immutability and if String would not have been immutable, then caching string objects and reusing them would not have been a possibility because any variable would have changed the value and corrupted others.

2. Thread Safety

An object is called thread-safe when multiple threads are operating on it but none of them is able to corrupt its state and object holds the same state for every thread at any point in time.

As we know an immutable object cannot be modified by anyone after its creation which makes every immutable object thread safe by default. We do not need to apply any thread safety measures to it such as creating synchronized methods.

So due to its immutable nature string object can be shared by multiple threads and even if it is getting manipulated by many threads it will not change its value.

3. Security

In every application, we need to pass several secrets e.g. user's user-name\passwords, connection URLs and in general, all of this information is passed as string objects.

Now suppose if String would not have been immutable in nature then it could cause serious security threats to the application because these values will be allowed to get changed and if it is allowed then these might get changed due to wrongly written code or by any other person who has access to our variable references.

4. Class Loading

As discussed in Creating objects through Reflection in Java with Example, we can use Class.forName("class_name") method to load a class in memory which again calls other methods to do so and even JVM uses these methods to load classes.

But if you see clearly all of these methods accepts the class name as a string object so Strings are used in java class loading and String's immutability makes sure that correct class is getting loaded by ClassLoader.

Suppose if String would not have been immutable and we are trying to load java.lang.Object which get changed to org.theft.OurObject in between and now all of our objects have a behavior which someone can use to do unwanted things.

5. HashCode Caching

If we are going to perform any hashing related operations on our object we must override the hashCode() method and try to generate an accurate hashcode by using the state of the object. If object's state is getting changed which means its hashcode should also change.

Because String is immutable so the value one string object is holding will never get changed which means its hashcode will also not change which gives String class an opportunity to cache its hashcode during object creation.

Yes, String object caches its hashcode at the time of object creation which makes it a great candidate for hashing related operations because hashcode doesn't need to be calculated again and again which save us some time and this is why String is the most suitable candidate to be used as HashMap keys.

Disadvantages of String Immutability


There are always two sides to a coin, whenever something is providing us some benefits it will also a have some drawbacks and String's immutability also falls into it.

1. PermGen Space Error

Due to the immutability of String, string object can't be changed and whenever we make a change on it, JVM creates a new string object. So if there are 10000 string object in an application and every string object is getting manipulated 10 times then we are left with 110000 string objects.

And as we know strings are stored in a separate constant pool which is part of Permanent Generation, which usually occupies very limited memory as compared to young and old generations. Having too many String literals will quickly fill this space, resulting in java.lang.OutOfMemoryError: PermGen Space error.

2. Keeping passwords in memory for a long time

In general, passwords are stored as strings and strings are stored in the constant pool which is exempted from normal garbage collection cycles. So our password might remain in memory for very long time and someone can take advantage of it.

This is the reason standards suggest to hold password in an char[] array instead of the string object.

3. String is not extensible

Making String final is part of making it immutable but it also becomes a disadvantage because it limits its extensibility and we cannot extend String to provide more functionality.

For some developers, it becomes a problem when they require some extra behavior for their string objects but it's not a disadvantage and it can be tacked by creating a utility method which accepts the string as a parameter.

You can find complete code on this Github Repository and please feel free to provide your valuable feedback.


In a previous article Why String is Immutable and Final in Java, I have discussed why String is immutable in nature and advantages and disadvantages String's immutability gives us.

I have also discussed that, all String literals are cached into a special memory area called String Constant Pool and how String's immutability made String constant pool possible.

But the question arises why do Java required a separate constant pool to store Strings, What's the reason, Why strings are not stored in the normal heap memory like other objects do and in this article, I will try to answer these questions.

String Interning

Well, we know String is the most popular type present in Java and almost all Java programs use it. In fact, I have not seen a single Java program which is written without using String.

In general, a normal Java business application deals with thousands of string objects, lots of them have same value associated and lots of them are mid operations string means they are not the final result.

So if we store all those string objects in normal heap memory, lot's of heap will be acquired by just string objects only, and the garbage collector will have to run more frequently which will decrease the performance of the application.

And that's why we have String Constant Pool and String interning process, whenever we create a string literal JVM first sees if that literal is already present in the constant pool or not and if it is there, the new variable will start pointing to the same object, this process is called String Interning.

There are two ways to create a String object
  1. Creating String Literal:: Anything which comes under "" is a string literal e.g. String s1 = "Naresh", by default all string literals interned and goes to SCP.
  1. Creating String object using constructor: If we create a String object using the constructor e.g. String s2 = new String("Naresh"), the object is created in normal heap memory instead of SCP. And that's why creating String object using constructor is not considered a best practice. We can ask s2 to point to SCP instead of normal heap manually by calling intern() method on it i.e. s2.intern().
So in order to save memory consumed by string objects, Java allows more than one reference variable to point to the same object if they have the same value. That's why JVM creators have created a separate memory area SCP for string literals and made a rule that if more than one string variable holding same value than they will point to the same object.

String a = "Naresh";
String b = "Naresh";
String c = "Naresh";

For above code there will be only one object Naresh will be created and all reference variables a, b, c will point to the same object.

In above example string object with value Naresh will get created in SCP only once and all reference a, b, c will point to same object but what if we try to make a change in a e.g. a.replace("a", "").

Ideally, a should have value Nresh but b, c should remain unchanged because as an end user we are making the change in a only. And we know a, b, c all are pointing the same object so if we make a change in a, others should also reflect the change.

string-constant-pool-in-java

But string immutability saves us from this scenario and due to the immutability of string object string object Naresh will never change. So when we make any change in a instead of change in string object Naresh JVM creates a new object assign it to a and then make the change in that object.

So String pool is only possible because of String's immutability and if String would not have been immutable, then caching string objects and reusing them would not have a possibility because any variable would have changed the value and corrupted others.

You can find complete code on this Github Repository and please feel free to provide your valuable feedback.

Java allows us to declare a variable whenever we need it, We can categorize all our variables into 3 categories which have different-different scopes
  1. Instance Variables - Defined inside a class and have object level scope.
  2. Class Variables - Defined inside a class with static keyword, have class level scope common to all objects of the same class
  3. Local Variables - Defined inside a method or in any conditional block, have the block-level scope and only accessible in the block where it defined.
what-is-variable-hiding-shadowing

What is Variable Shadowing

Variable shadowing happens when we define a variable in a closure scope with a variable name and we have already defined a variable in outer scope with the same name.

In other words, when a local variable has the same name as one of the instance variable, the local variable shadows the instance variable inside the method block.

In the following example, there is an instance variable named x and inside method printLocalVariable(), we are shadowing it by the local variable x.

class Parent {

    // Declaring instance variable by name `x`
    String x = "Parent`s Instance Variable";

    public void printInstanceVariable() {
        System.out.println(x);
    }

    public void printLocalVariable() {
        // Shadowing instance variable `x` by a local variable with same name
        String x = "Local Variable";
        System.out.println(x);

        // If we still want to access instance variable, we do that by using `this.x`
        System.out.println(this.x);
    }
}

What is variable Hiding

Variable Hiding happens when we define a variable in child class with a variable name which we have already used to define a variable in the parent class. A child class can declare a variable with the same name as an inherited variable from its parent class, thus hiding the inherited variable.

In other words, when the child and parent class both have a variable with same name child class's variable hides parent class's variable.

In the below example, we are hiding the variable named x in the child class while it is already defined by its parent class.

class Child extends Parent {

    // Hiding Parent class's variable `x` by defining a variable in child class with same name.
    String x = "Child`s Instance Variable";

    @Override
    public void printInstanceVariable() {
        System.out.print(x);

        // If we still want to access variable from super class, we do that by using `super.x`
        System.out.print(", " + super.x + "\n");
    }
}

Variable Hiding is not same as Method Overriding

While variable hiding looks like overriding a variable similar to method overriding but it is not, Overriding is applicable only to methods while hiding is applicable variables.

In the case of method overriding, overridden methods completely replaces the inherited methods so when we try to access the method from parent's reference by holding child's object, the method from child class gets called. You can read more about overriding on Everything About Method Overloading Vs Method Overriding, Why We Should Follow Method Overriding Rules, How Does JVM Handle Method Overloading and Overriding Internally.

But in variable hiding child class hides the inherited variables instead of replacing, so when we try to access the variable from parent's reference by holding child's object, it will be accessed from the parent class.

When an instance variable in a subclass has the same name as an instance variable in a super class, then the instance variable is chosen from the reference type.

public static void main(String[] args) throws Exception {

    Parent parent = new Parent();
    parent.printInstanceVariable(); // Output - "Parent`s Instance Variable"
    System.out.println(parent.x); // Output - "Parent`s Instance Variable"

    Child child = new Child();
    child.printInstanceVariable();// Output - "Child`s Instance Variable, Parent`s Instance Variable"
    System.out.println(child.x);// Output - "Child`s Instance Variable"

    parent = child; // Or parent = new Child();
    parent.printInstanceVariable();// Output - "Child`s Instance Variable, Parent`s Instance Variable"
    System.out.println(parent.x);// Output - Parent`s Instance Variable

    // Accessing child's variable from parent's reference by type casting
    System.out.println(((Child) parent).x);// Output - "Child`s Instance Variable"
}

In above example when we call overridden method printInstanceVariable() on parent while holding Child's object in it we can see the output is Child`s Instance Variable, Parent`s Instance Variable because in child class method is printing Child class's x variable and super.x.

But when we call System.out.println(parent.variable); on same parent reference which is holding child's object, it prints Parents Instance Variable because new Child() object keeps parent's x as well as child's x and hides parent's x. So, in this case, x is chosen from the class that is the reference type.

But if we wanted to access child's variable even if we are using parent reference we can do that by using (Child) parent).variable.

When our variables are private or is in another package and has default access, such variables are not visible outside that class and child class cannot access them. So there no confusion and that is why we should always stick to General Guidelines to create POJOs and declare our variables with private access and also provide proper get/set methods to access them.

You can find complete code on this Github Repository and please feel free to provide your valuable feedback.

In my previous articles Why Should We Follow Method Overloading Rules, I discussed about method overloading and rules we need to follow to overload a method. I have also discussed why we need to follow these rules and why some method overloading rules are necessary and others are optional.

In a similar manner in this article, we will see what rules we need to follow to override a method and why we should follow these rules.

Method Overriding and its Rules

As discussed in Everything About Method Overloading Vs Method Overriding, every child class inherits all the inheritable behaviour from its parent class but the child class can also define its own new behaviours or override some of the inherited behaviour.

Overriding means redefining a behaviour (method) again in the child class which was already defined by its parent class but to do so overriding method in the child class must follow certain rules and guidelines.

With respect to the method it overrides, the overriding method must follow following rules.
Why We Should Follow Method Overriding Rules

To understand these reasons properly let's consider below example where we have a class Mammal which defines readAndGet method which is reading some file and returning an instance of class Mammal.

Class Human extends class Mammal and overrides readAndGet method to return instance of Human instead of instance of Mammal.

class Mammal {
    public Mammal readAndGet() throws IOException {//read file and return Mammal`s object}
}

class Human extends Mammal {
    @Override
    public Human readAndGet() throws FileNotFoundException {//read file and return Human object}
}

And we know in case of method overriding we can make polymorphic calls. Which means if we assign a child instance to a parent reference and call an overridden method on that reference eventually the method from child class will get called.

Let's do that

Mammal mammal = new Human();
try {
    Mammal obj = mammal.readAndGet();
} catch (IOException ex) {..}

As discussed in  How Does JVM Handle Method Overloading and Overriding Internally till compilation phase compiler thinks the method is getting called from the parent class. While bytecode generation phase compiler generates a constant pool where it maps every method string literal and class reference to a memory reference

During runtime JVM creates a vtable or virtual table to identify which method is getting called exactly. JVM creates a vtable for every class and it is common for all the objects of that class. Mammal row in a vtable contains method name and memory reference of that method.

First JVM creates a vtable for the parent class and then copy that parent's vtable to child class's vtable and update just the memory reference for the overloaded method while keeping the same method name.

You can read it more clearly on  How Does JVM Handle Method Overloading and Overriding Internally if it seems hard.
So as of now we are clear that
  • For compiler mammal.readAndGet() means method is getting called from instance of class Mammal
  • For JVM mammal.readAndGet() is getting called from a memory address which vtable is holding for Mammal.readAndGet() which is pointing to a method call from class Human.

Why overriding method must have same name and same argument list

Well conceptually mammal is pointing to an object of class Human and we are calling readAndGet method on mammal, so to get this call resolved at runtime Human should also have a method readAndGet. And if Human have inherited that method from Mammal then there is no problem but if Human is overriding readAndGet, it should provide the same method signature as provided by Mammal because method has been already got called according to that method signature.

But you may be asking how it is handled physically from vtables so I must tell you that, JVM creates a vtable for every class and when it encounters an overriding method it keeps the same method name (Mammal.readAndGet()) while just update the memory address for that method. So both overridden and overriding method must have same method and argument list.

Why overriding method must have same or covariant return type

So we know, for compiler the method is getting called from class Mammal and for JVM call is from the instance of class Human but in both cases, readAndGet method call must return an object which can be assigned to obj. And since obj is of the type Mammal it can either hold an instance of Mammal class or an instance of a child class of Mammal (child of Mammal are covariant to Mammal).

Now suppose if readAndGet method in Human class is returning something else so during compile time mammal.readAndGet() will not create any problem but at runtime, this will cause a ClassCastException because at runtime mammal.readAndGet() will get resolved to new Human().readAndGet() and this call will not return an object of type Mammal.

And this why having a different return type is not allowed by the compiler in the first place.

Why overriding method must not have a more restrictive access modifier

The same logic is applicable here as well, call to readAndGet method will be resolved at runtime and as we can see readAndGet is public in class Mammal, now suppose
  • If we define readAndGet as default or protected in Human but Human is defined in another package
  • If we define readAndGet as private in Human
In both cases code will compile successfully because for compiler readAndGet is getting called from class Mammal but in both cases, JVM will not be able to access readAndGet from Human because it will be restricted.

So to avoid this uncertainty, assigning restrictive access to the overriding method in the child class is not allowed at all.

Why overriding method may have less restrictive access modifier

If readAndGet method is accessible from Mammal and we are able to execute mammal.readAndGet() which means this method is accessible. And we make readAndGet less restrictive Human which means it will be more open to get called.

So making the overriding method less restrictive cannot create any problem in the future and that's it is allowed.

Why overriding method must not throw new or broader checked exceptions

Because IOException is a checked exception compiler will force us to catch it whenever we call readAndGet on mammal

Now suppose readAndGet in Human is throwing any other checked exception e.g. Exception and we know readAndGet will get called from the instance of Human because mammal is holding new Human().

Because for compiler the method is getting called from Mammal, so the compiler will force us to handle only IOException but at runtime we know method will be throwing Exception which is not getting handled and our code will break if the method throws an exception.

That's why it is prevented at the compiler level itself and we are not allowed to throw any new or broader checked exception because it will not be handled by JVM at the end.

Why overriding method may throw narrower checked exceptions or any unchecked exception

But if readAndGet in Human throws any sub-exception of IOException e.g., FileNotFoundException, it will be handled because catch (IOException ex) can handle all child of IOException.

And we know unchecked exception (subclasses of RuntimeException) are called unchecked because we don't need to handle them necessarily.

And that's why overriding methods are allowed to throw narrower checked and other unchecked exceptions.

To force our code to adhere method overriding rules we should always use @Override annotation on our overriding methods, @Override annotation force compiler to check if the method is a valid override or not.

You can find complete code on this Github Repository and please feel free to provide your valuable feedback.
In my previous articles, Everything About Method Overloading Vs Method Overriding and How Does JVM Handle Method Overloading and Overriding Internally, I have discussed what is method overloading and overriding, how both are different than each other, How JVM handles them internally and what rules we should follow in order to implement these concepts.

In order to overload or override a method we need to follow certain rules, some of them are mandatory while others are optional and to become a good programmer we should always try to understand the reason behind these rules.

I am going to write two articles where I will try to look into the method overloading and overriding rules and try to figure out why we need to follow them.

In this article, we will see what rules we should follow to overload a method and we will also try to know why we should follow these rules.

Method Overloading

In general, method overloading means reusing same method name to define more than one method but all methods must have a different argument list.

We can take the example of the print method present in PrintStream class which gets called when we call System.out.print() to print something. By calling this method on several data types it seems like there is just one print method which is accepting all types and printing their values.

But actually, there are 9 different print methods as shown in below image

method-overloading

Well, the PrintStream class creator could have created methods like printBoolean or printInt or printFloat, but the idea behind naming all the 9 methods same is to let the user think that there is only one method which is printing whatever we pass to it.

Which sounds like polymorphism but as discussed in the article How Does JVM Handle Method Overloading and Overriding Internally that how method overloading get resolved at compile time, some people also term method overloading as compile-time polymorphism.

Method Overloading Rules

While defining a method we need to provide it a proper method signature which includes access specifier, return type, method name, argument list, exceptions method might throw. Based on these five things method overloading has some mandatory rules and some optional rules, which we are going to see below.

Mandatory Rules

  • Overloaded methods must have same method name: Having the same name let us reuse the same method name for different purposes and let the user believe that there is only one method which is accepting different kinds of input and doing the work according to the input.
  • Overloaded methods must have different argument lists: Since all overloaded methods must have the same name, having a different argument list becomes necessary because it is the only way to differentiate the methods from each other. Java compiler differentiates a method from other based on its method name and argument list, So different argument list helps the compiler to differentiate and recognize methods from each other so the compiler will know which method is getting called at compile time only.

Optional Rules

The compiler knows that at the time of method calling JVM needs to know the method name and JVM will pass some arguments to that method so it must also know the argument list. While other method signature elements e.g. return type, access modifier, the exception method throwing also matter but at the time of method call they become optional.

So the different argument list is sufficient for the compiler to differentiate between the methods even if they have the same name so rules mentioned below are optional and we are free to follow or not follow them. Going with below rules totally depends on your requirements and they are there to just provide us additional functionality.
  • Overloaded methods can have different return types: Return type matters when the method call is finished and JVM assigning back the value returned by that method call to some variable. But it is not required while calling the method and JVM cannot use it to differentiate between methods based on just return type. So we can either return the same as the overloaded method did or return something different or return nothing.
  • Overloaded methods can have different access modifiers: If a method is getting called by the JVM it means it has passed the compilation phase because executing the bytecode which is already compiled. So access specifier of a method is useful for the compiler but it is useless for JVM and JVM cannot differentiate between methods based on access modifier. So an overloading method can have any access modifier and we can use it according to our need.
  • Overloaded methods can throw different checked or unchecked exceptions: Again what exceptions a method might throw cannot differentiate a method from another method.And also overloaded methods are different from each other but usually, they perform the same operation on different data set and in order to do so overloaded methods may do some different operation as well which may throw a different exception.
You can find complete code on this Github Repository and please feel free to provide your valuable feedback.
Previous Post Older Posts Home