Learning Java - Core Concepts & Main Architecture

#Introduction

Episode 1 explained why Java exists. Episode 2 discusses how Java works. This is the most fundamental episode in the entire series: you will dissect the JVM architecture, understand the differences between JDK, JRE, and JVM, and get to know the project structure and the class management mechanism.

This understanding is not just theory. When you face errors such as ClassNotFoundException or NoClassDefFoundError, or when you have to configure the classpath for external libraries, the knowledge from this episode will be your lifesaver.

#The Compilation Process: From Source Code to Bytecode

#The Flow from .java to .class

Every Java program starts as a source file with the .java extension. The javac compiler turns it into bytecode with the .class extension. Bytecode is not native machine code; it is platform-neutral instructions for the JVM.

The flow is simple: source code .java is compiled into bytecode .class, then executed by the JVM. To see the result, create a file named Halo.java and run:

public class Halo {
    public static void main(String[] args) {
        System.out.println("Halo dari JVM");
    }
}

Compile and run:

javac Halo.java
java Halo

javac Halo.java produces Halo.class, and java Halo loads and executes that class on the JVM. Notice that the java command uses the class name, not the file name.

#Inspecting Bytecode with javap

To see the contents of the bytecode, use the javap tool:

javap -c Halo

javap -c Halo shows bytecode instructions such as getstatic and invokevirtual. This proves that Java does not execute machine code directly, but virtual instructions run by the JVM.

#The JVM Architecture

#Four Core JVM Components

The JVM works through several collaborating components:

• Class loader: loads .class files into memory when needed.
• Bytecode verifier: validates bytecode so it is safe and conforms to the language rules.
• JIT compiler: compiles frequently executed bytecode into machine code for performance.
• Garbage collector: cleans up objects that are no longer used.

#Execution Flow and JVM Lifecycle

When java is run, the class loader loads the main class along with its dependencies, the verifier checks the safety of the bytecode, then the interpreter or JIT compiler executes the instructions. The JVM also manages heap memory, monitors threads, and runs garbage collection periodically.

load class -> verify bytecode -> interpret / JIT compile -> run & collect garbage

#The Roles of JVM, JRE, and JDK

#Three Layers Often Mixed Up

• JVM (Java Virtual Machine): the virtual machine that runs bytecode. This is the only part that actually executes programs.
• JRE (Java Runtime Environment): contains the JVM plus the standard libraries needed to run applications.
• JDK (Java Development Kit): contains the JRE plus the javac compiler and development tools needed to create applications.

JDK berisi JRE berisi JVM

To develop applications, you need the JDK. To simply run applications, the JRE is enough. That is why we installed the JDK in episode 0 — because this series also involves writing code.

#The Standard Java Project Structure

#Standard Directory Layout

Modern Java projects follow a standard structure that Maven and Gradle understand:

• src/main/java: main source code.
• src/test/java: test source code.
• src/main/resources: configuration files and non-Java assets.

This structure is a convention that makes projects easy to understand and automate.

#Packages and Dependency Management

A package groups classes into namespaces to avoid name conflicts. The convention uses reversed domain names, for example com.perusahaan.aplikasi. Packages are also the foundation of dependency management and modules.

#Classpath, Module Path, and JPMS

#Classpath: Where Classes Are Found

The classpath tells the JVM where to find classes and libraries. When running a program with external dependencies, you set the classpath with the -cp flag:

java -cp .:lib/library.jar com.aplikasi.Main

-cp .:lib/library.jar tells the JVM to look for classes in the current directory and in the JAR file. If a library is not found on the classpath, a ClassNotFoundException appears.

#Module Path and JPMS

Java 9 introduced the Java Platform Module System (JPMS) as a modern dependency management feature. Modules are declared in a module-info.java file and run via the module path, not the classpath. JPMS provides stronger encapsulation because each module declares which packages it exports.

classpath: daftar direktori dan JAR, tidak ada batasan akses
module path: modul dengan deklarasi requires dan exports

Episode 18 will cover JPMS in depth. For now, understand that the classpath is the classic mechanism, while the module path is its modern evolution.

#Closing

Episode 2 dissects the technical foundations of Java: the compilation process from source code to bytecode, the JVM architecture with its four core components, the differences between JDK, JRE, and JVM, the standard project structure, and the classpath and module path mechanisms.

Key takeaways:

• javac turns source code into .class bytecode, then java executes it on the JVM.
• The JVM consists of the class loader, bytecode verifier, JIT compiler, and garbage collector.
• JDK contains JRE which contains JVM: JDK for development, JRE for running.
• The standard structure is src/main/java, src/test/java, and src/main/resources.
• The classpath points to where classes are; JPMS provides modern module encapsulation.
• A ClassNotFoundException is usually caused by a wrong classpath.

In the next episode, episode 3, we will discuss basic syntax and Java code structure — your first program, class declarations, methods, fields, and access visibility, statements, blocks, comments, naming rules, and running applications from the command line and IDE. Time to write real code!