#java internal

[javaonjava]

Need for Immutable String in Java

While understanding String Immutability there were some answered questions as to why the designers of Java made String Immutable. We checked that String is immutable but Why so?

Well, it's difficult to go inside the brain of designers of java but based on the usage as of today we can speculate as to what would have been going on in their brain while making java immutable.

1. Easy storage and housekeeping

Strings are used a lot inside a program. A lot of Strings are repeated. For example in a College Database application, same names (Strings) are repeated again and again. Hence it makes better sense to keep a single copy of all strings at a single place (String Pool). Instead of creating new objects again and again. Garbage Collection and Storage of these high volume data becomes easy.

2. Hashcode does not change

Since Strings are immutable, their hascode won't change like other objects. Thus Strings do not calculate hashcode every time we call hashcode function, Hascode us kept cached. Since Strings are used a keys in HashMaps and other such Structures, we save a lot of time but not calculating hashcode every time we need to retrieve an Object.

3. Network Security

All passwords we enter online are strings. Bank details are passed as Strings. If they are mutable, anyone could change them over the network, which would wreak havoc. Same goes with classnames while loading a Class. 

4. Prevents Concurrency Issues

Since Strings are immutable, hence no need to synchronize. Hence no concurrency issues while using Strings.

[javaonjava]

String immutable in Java: What does it really mean?

This is one of the favourite questions at the fresher level that interviewer asks. Most of the candidates tend to gloss over this. If interviewer tends to go into this deep, most of the candidates tend to falter. At least that if what I have observed having interviewed hundreds of candidates in the past.

We will try and make this article single point of reference for Strings in Java. Hopefully we cover something that might be helpful to you. Read here, for knowing Why It was made Immutable.

Let's try and go in depth on String immutability.

Let's start by Source Code of String.java. I always say that source code is the best resource to learn a language.

How String is Immutable? This question is self answered by the above code snippet. Member variable data type is final. Hence String Object once created becomes immutable in Java.

How come then we are able to assign same variable, a different value? Now we are talking. Valid question. Let's check it via code, So the question stands. What does immutability means? Well, it can be explained by what happens internally. Variable immutable refers to a memory space which is allocated to "javaonjava. This memory allocation is what we call immutable. Same variable can point to different memory spaces. String literals are stored separately in a String Pool. Once a String is Created, say "javaonjava". Whenever a new variable needs "javaonjava" String, a new String is not created. The old one is referenced. This is what we mean by immutability. So String Object is not immutable, String itself is immutable. Compare it with any User defined object. When that object is updated, content is re-written on the same memory space. Hope things are getting clear now. How to check String is immutable in Java 1. == (equals operator), is the best check. As we read above StringPool contains single copy of a given String. So if this operator returns true on two string variables, it means they are pointing to same memory and content inside the StringPool Thus we see, they both point to the same content. 2. No operations modify String Thus we see neither concat, nor substring modifies the String. They simply create a new String, which is returned as we see below. In the last example, what happens to "javaonjava" String. Well it remains in the StringPool but unreferenced. If not reused for considerable time, it could be Garbage Collected. See the diagram below for better understanding

[javaonjava]

Primitive Data Types Java

Total 8 primitive types are supported by Java.

Data types is nothing but a way to assign different size of memory space to different data. Depending on the size required to store the data, memory space is allocated to it.

To make things easy, In Java we call such memory spaces by name as below,

Data Type

Size

Default Value

Min

Max

boolean

1 bit

false

false

true

char

2 byte

'\u0000'

'\u0000' (or 0)

'\uffff' (or 65,535)

byte

1 byte

0

-128 (-2^7)

127 (2^7 -1)

short

2 byte

0

-32,768 (-2^15)

32,767 (2^15 -1)

int

4 byte

0

- 2,147,483,648 (-2^31)

2,147,483,647 (2^31 -1)

long

8 byte

0L

-9,223,372,036,854,775,808

(-2^63)

9,223,372,036,854,775,807

(2^63 -1)

float

4 byte

0.0f

double

8 byte

0.0d

[javaonjava]

JDK JRE JVM

When we say Java is Platform independent, we mean that same code can run seamlessly on Windows/Linux/Mac machines. We need not change our code or make any special provision in the code to run it on different machines. Such provision is very common in C/C++ code (like porting the code from Windows to Linux), where we instruct the program to run certain parts in linux and bypass them while running on Windows and vice-versa. Its not the case with Java. This is achieved by three simple terms that we will discuss here JDK JRE JVM, the eternal triumvirate.

The relationship can be understood by the diagram below, which we will explore in detail.

JVM (Java Virtual Machine)

It is primarily JVM that makes Java platform independent. As the name suggests it is a Java Virtual Machine. Real Machine is the linux box (real piece of hardware) on which we run our application. Virtual Machine is a layer on top of the real hardware. For those who interact with it, JVM acts as though it is the real boss (Machine). But in reality it’s just a Software Hoax.

Like any Computing Machine, it comes with the caravan of instruction sets and power to play with memory. For different platforms (Windows/Linux/Mac), we have different implementations of JVM. These interact with different Machines in different ways but provide a uniform Virtual Environment. Java program needs to interact just with this Virtual Machine and not the Real Machine, making Java Platform independent. Different JVM implementations might differ, mostly in areas which are not covered by specification provided by Java and does not affect the results of a Java program. These are areas like garbage collection, performance etc.

JVM takes  Java bytecode as input, which it interprets into Machine code compatible to specific Hardware on which JVM is running. To run a program JVM uses class libraries and java.exe provided in the JRE.

Java Bytecode: JVM does not understand *.java files. JDL compiled *.java files and create *.class files, which contain bytecode and understood by JVM. If we take the same bytecode and run it on different enviroments, due to the JVM which is uniform, we will get same results.

This make life simpler for developers,  isn’t it? Why worry about where the code will run. Just write the code and be done.

Compiler compiles the code in a bytecode for a Virtual Processor (JVM) which in turn converts it into Machine code for a Real Processor (LinuX/Windows platform).

JRE (Java Runtime Environment)

Various implementations of JVM which are installed on various Platforms are called JRE (Java Runtime Environment). This is the software which runs and interact with the Real Hardware and provide a JVM. It also contains the libraries required to run applications. Note that it cannot complie the code. It can just provide JVM and libaries which can run a comiled code (bytecode). For compiling the code we need JDK.

In effect JRE = JVM + Few Java packages + Runtime libaries (java.exe)

How it happens is, JVM will run a program using runtime libararies and other files which are there in a JRE. If JRE is missing you cannot run a Java program.

JDK (Java Developer Kit)

This is the Ace among the three. It contains JRE, JVM and compiler (javac.exe) along with other things. With JDK one is able to compile (convert *.java to *.class bytecode) and run (java.exe) a program. It is maily for developers. Without JDK installed there is no point writing a Java code as you will not be able to compile and test it.

Normally if you get a Windows machine to work on, you wont find JDK installed by default. You would just be having JRE (required to run online games which were complied by JDK). Apart from that a lot of softwares we want to run on Windows have JDK compiled code which again requires JRE to run. We need to install JDK separately.

Source code (Test.java) is converted to Test.class (bytecode) by javac.exe compiler tool. Then java.exe (application launcher in JRE) runs it on JVM (which converts bytecode to machine code and run it on OS).