Java is highly scalable. Take the case of Java EE. Assuming you have done the right planning and used the right kind of application server, the Java EE can transparently cluster instances. It also allows multiple instances to serve requests.

In Java, separation concerns allow better scaling. When processing or the number of Input-Output (IO) requests increases, you can easily add resources, and redistribute the load. Separation of concerns makes this transparent to the app.

Java components are easily available, making scaling of large web apps easy. The language is flexible, and you need to do less invasive coding to improve scalability. Read more about it in this StackOverflow thread on Java scalability.

One great advantage of Java is “Write Once, Run Everywhere”. We also call this feature ’portability’. You can execute a compiled Java program on all platforms that have a corresponding JVM.

This effectively includes all major platforms, e.g. Windows, Mac OS, and Linux. Read more about the cross-platform feature of Java in this StackOverflow thread titled “Is Java cross-platform”.

You first write your Java program in the “.java” file. Subsequently, you compile it using the Ecplise IDE or ’javac‘, and thereby you create your “.class” files. While it isn‘t mandatory, you can also bundle your “.class” file into a “.jar” file, i.e. an executable.

You can now distribute your “.jar” file to Windows, Mac OS, and Linux, and run it there. There may be occasional confusion, because you may find different set-up files for different platforms for one Java program. However, these have nothing to do with Java.

There are applications that depend on specific features certain platforms provide. For such apps, you need to bundle your Java “.class” files with libraries specific to that platform.

Java’s automatic memory management is a significant advantage. I will describe it briefly here to show how it improves the effectiveness and speed of web apps.

In programming parlance, we divide memory into two parts, i.e. the ’stack’ and the ’heap’. Generally, the heap has a much larger memory than the stack.

Java allocates stack memory per thread, and we will discuss threads a little later in this article. For the time being, note that a thread can only access its own stack memory and not that of another thread.

The heap stores the actual objects, and the stack variables refer to these. The heap memory is one only in each JVM, therefore it‘s shared between threads. However, the heap itself has a few parts that facilitate garbage collection in Java. The stack and heap sizes depend on the JVM.

Now, we will analyze the different types in which the stack references the heap objects. The different types have different garbage collection criteria. Read more about it in “Java Memory Management”.

Following are the reference types:

1. Strong: It‘s the most popular, and it precludes the object in the heap from garbage collection.
2. Weak: An object in the heal with a weak reference to it from the stack may not be there in the heap after a garbage collection.
3. Soft: An object in the heap with a soft reference to it from the stack will be left alone most of the time. The garbage collection process will touch it only when the app is running low on memory.
4. Phantom reference: We use them only when we know for sure that the objects aren‘t there in the heap anymore, and we need to clean up.

The garbage collection process in Java runs automatically, and it may pause all threads in the app at that time. The process looks at the references that I have explained above and cleans up objects that meet the criteria.

It leaves the other objects alone. This entire process is automated; therefore, the programmers can concentrate on their business logic if they follow the right standards for using reference types.