Java Introduction

Introduction

Java was born in 1995 when James Gosling's team at Sun Microsystems needed a language for interactive TV set-top boxes — devices with unreliable hardware and strict memory limits. The project was codenamed Green; the language was first called Oak, then renamed Java. The original pitch was "Write Once, Run Anywhere": compile source to portable bytecode, ship a .class file, and let any device with a Java Virtual Machine (JVM) execute it.

Thirty years later, Java is not a set-top-box language. It is the default choice for enterprise backends, Android (via Kotlin/JVM bytecode), big-data infrastructure (Kafka, Hadoop, Cassandra, Elasticsearch), and financial trading systems where uptime and auditability matter more than hype cycles. Oracle owns the Java trademark; the reference implementation is OpenJDK, governed openly with contributions from Red Hat, Amazon, Microsoft, and Azul.

Business problem

Why enterprises still standardize on Java in 2026:

• Regulated industries (banking, insurance, healthcare) need languages with 20+ years of audit trail, backward compatibility, and predictable LTS support — not framework churn every 18 months.
• Scale economics: A JVM service running for months amortizes JIT compilation cost; throughput on long-lived servers often beats interpreted or cold-start-heavy alternatives.
• Talent & tooling: IntelliJ IDEA, Maven/Gradle, Spring, Micrometer, and millions of Stack Overflow answers reduce time-to-production versus niche stacks.
• Multi-vendor JVM: Amazon Corretto, Eclipse Temurin, Azul Zulu, GraalVM — no single vendor lock-in on the runtime.

Why this topic exists

The problem Java solved in 1995 still exists: heterogeneous hardware, long-lived deployments, and teams that cannot recompile the entire world every time an OS updates.

• C/C++ pain: Platform-specific binaries, manual memory management, pointer bugs in production.
• Java's bet: Managed memory (GC), bytecode portability, strict typing at compile time.
• Rejected alternative: Pure interpreted scripts — too slow for enterprise throughput; native-only — too brittle across deploy targets.
• Modern evolution: Virtual threads (Project Loom), records, sealed classes — Java absorbs modern ergonomics without breaking the compatibility contract.

Core concepts

Core concepts every Java engineer must internalize:

• JDK vs JRE vs JVM: JDK = develop (javac, javadoc, jfr); JRE = run (deprecated as standalone); JVM = executes bytecode.
• Bytecode: Not machine code — platform-independent instructions verified before execution.
• Garbage collection: Automatic reclamation; tune G1/ZGC for latency-sensitive services.
• Static typing: Types checked at compile time — catches entire classes of bugs before deploy.
• Release cadence: Feature release every 6 months; LTS every 2 years (8 → 11 → 17 → 21 → 25).
• Java 21 (LTS): Virtual threads, sequenced collections, pattern matching for switch, record patterns, generational ZGC — the 2026 enterprise baseline.

Internal architecture

From source code to running service — the internal path every .java file follows:

Main.java  ──javac──▶  Main.class (bytecode)
                              │
                              ▼
                    Class Loader (loads .class into Metaspace)
                              │
                              ▼
                    Bytecode Verifier (safety checks)
                              │
                              ▼
                    Interpreter (cold path) ──hot──▶ JIT (C1/C2) ──▶ native code
                              │
                              ▼
                    Garbage Collector (G1 / ZGC / Shenandoah)
                              │
                              ▼
                    OS threads + hardware

Three architecture views — platform stack, release train, and enterprise adoption:

Code walkthrough

Minimal Java program — every line maps to JVM concepts above:

• public class Main — top-level class; one public class per file.
• static void main — JVM contract; no main → no standalone execution.
• System.out — PrintStream wired to stdout; production uses SLF4J + Logback.

// Main.java — public class name MUST match filename
public class Main {
    // JVM entry point — called by runtime via reflection
    public static void main(String[] args) {
        System.out.println("Java " + Runtime.version());
        // Runtime.version() → e.g. 21.0.2+13-LTS on Temurin 21
    }
}

// Compile:  javac Main.java   → Main.class (bytecode)
// Run:       java Main         → JVM loads, verifies, executes

Production example

Production service skeleton — how Java Introduction concepts appear in a real Spring Boot deployable:

• Java 21 LTS in toolchain — virtual threads enabled in Spring Boot 3.2+.
• Temurin JRE — slim container image; no JDK in production.
• ZGC — low-latency GC flag common on payment and trading services.

// build.gradle.kts
plugins { id("org.springframework.boot") version "3.4.0" }
java { toolchain { languageVersion.set(JavaLanguageVersion.of(21)) } }

// Application.java
@SpringBootApplication
public class PaymentApplication {
    public static void main(String[] args) {
        SpringApplication.run(PaymentApplication.class, args);
    }
}

// Dockerfile — production baseline
FROM eclipse-temurin:21-jre-alpine
COPY build/libs/app.jar /app.jar
ENTRYPOINT ["java", "-XX:+UseZGC", "-jar", "/app.jar"]

Enterprise case study

Netflix — Java at streaming scale: Netflix runs thousands of Java microservices behind Zuul/ Spring Cloud. Their engineering culture publishes JVM tuning guides, chaos engineering (Chaos Monkey), and migrated critical paths to Java 17+ for virtual-thread-ready stacks. Key lesson: Java wins not because it is fashionable — because decade-long services, massive hiring pool, and predictable LTS upgrades beat rewrite risk.

• Before: Per-service language fragmentation; inconsistent observability.
• Decision: Standardize on JVM + Spring ecosystem with paved-road templates.
• After: Shared libraries, consistent metrics (Atlas), faster incident response.

Performance considerations

Performance is a JVM discipline — not something you bolt on after launch:

• JIT warm-up: First requests after deploy are slower — use readiness probes, not liveness-only.
• GC choice: G1 default; ZGC/Shenandoah for sub-10ms pause targets on Java 21.
• Virtual threads: Java 21 — millions of lightweight threads for I/O-bound work without reactive complexity.
• Profiling: JFR (Java Flight Recorder) + async-profiler in production — not guesswork.

Security considerations

Java platform security — architectural, not optional:

• LTS patching: Oracle/Adoptium ship CVE fixes — running EOL Java 8 is a compliance failure.
• Security Manager (deprecated): Modern apps use container boundaries + OS sandboxing instead.
• Deserialization: Never deserialize untrusted bytes — RCE vector in legacy Java apps.
• Dependency scanning: OWASP Dependency-Check, Snyk on Maven/Gradle lockfiles.

Scalability considerations

Why Java scales horizontally in enterprise:

• Stateless services: Spring Boot pods scale behind K8s HPA — JVM heap sized per container limit.
• Thread models: Platform threads for CPU-bound; virtual threads for I/O-bound at 10× lower memory.
• Data tier separation: Java service layer scales independently of PostgreSQL/Kafka.
• Multi-region: Same bytecode runs in us-east-1 and eu-west-1 — no recompile per region.

Production challenges

Real production failures teams hit when they treat Java as "just another language":

• Metaspace OOM: Dynamic class generation (Hibernate, Groovy, bad frameworks) exhausts Metaspace — not heap.
• GC pause storms: Heap too small for traffic spike — tune or scale horizontally before blaming "Java is slow."
• Classpath hell: Duplicate SLF4J bindings, conflicting Jackson versions — enforce BOM in Gradle/Maven.
• Java 8 lock-in: Teams fear migration; miss virtual threads, records, text blocks — accumulate tech debt.

Common mistakes

• Learning Java 8 tutorials in 2026 — you miss 13 years of language and JVM improvements.
• Using System.out.println in production instead of structured logging (SLF4J + JSON appenders).
• Assuming "Java is slow" from cold-start micro-benchmarks — JVM wins on sustained throughput.
• Ignoring LTS calendar — running non-LTS (e.g. Java 22) in production without vendor support plan.
• Conflating Java the language with Spring — learn JVM fundamentals first, frameworks second.

Debugging guide

When Java misbehaves in production — staff engineer playbook:

• Read the stack trace bottom-up — root cause is often the deepest "Caused by".
• jcmd <pid> VM.flags — verify GC, heap, and container-aware settings.
• jfr start / jfr dump — capture 60s flight recording during incident.
• Heap dump: jcmd GC.heap_dump + Eclipse MAT for leak analysis.
• Version check: java -version on prod pod — mismatched local vs deploy is common.

# Quick production health check
java -version
jcmd 1 VM.uptime
jcmd 1 GC.heap_info
jcmd 1 Thread.print | head -50

Best practices

• Target Java 21 LTS for new services (2026 baseline); plan 25 LTS migration path.
• Use Eclipse Temurin or Amazon Corretto — free, patched, production-grade.
• Pin JDK in CI and Docker with same major version as production.
• Adopt records and sealed classes for DTOs and domain models — less boilerplate.
• Enable -XX:+HeapDumpOnOutOfMemoryError in all production JVM flags.

Anti-patterns

• Deploying fat JARs without layer caching — 200MB images rebuild from scratch every CI run.
• Sharing mutable static state across requests in Spring singletons — thread-safety bugs.
• Using new Integer() or boxing in hot loops — allocation pressure (use primitives).
• Big-bang Java 8 → 21 migration without dependency audit — breaks on removed APIs (javax → jakarta).

Staff engineer notes

• Staff engineers choose Java when the organization optimizes for predictability over novelty — hiring, LTS, bytecode portability, and 30 years of battle-tested libraries.
• Your job in architecture review is not "Java vs Go" religion — articulate workload fit: throughput, latency SLO, team skill, and migration cost.
• Java 21 virtual threads change the concurrency default — recommend platform threads only for CPU-bound work; document the decision in an ADR.
• At Amazon/Netflix scale, the JVM is treated as a managed runtime platform — GC, JFR, and container limits are first-class design inputs, not ops afterthoughts.

Interview questions

Hands-on exercise

Lab: Java platform discovery — run in the playground below, then answer:

• Print Runtime.version() and identify your JDK vendor.
• Print available processors and max memory — relate to container limits.
• Modify the program to print "Enterprise-ready" only if major version ≥ 21.
• Write one sentence: which LTS would you recommend for a new payment service and why.

Press Run to execute. Real javac + JVM via remote API. Falls back to simulator on network failure.

Architecture trade-offs

• Java vs native (Go/Rust): Java wins throughput + ecosystem on long-lived services; native wins cold start and memory for tiny binaries.
• LTS vs latest feature release: LTS wins support and compliance; feature releases win early access to preview APIs.
• HotSpot vs GraalVM native-image: HotSpot wins peak throughput; native-image wins startup time and RSS for serverless.

Summary

Java Introduction is not history trivia — it is the foundation for every architecture decision that follows. You now understand why Java dominates enterprise software, how the JVM executes your code, why LTS matters, what Java 21 delivers, and how companies like Netflix standardize on the platform. Next: set up JDK 21 and write production-grade Java.

Key takeaways

• Java was built for portability and longevity — WORA via bytecode + JVM still defines enterprise adoption.
• Standardize on Java 21 LTS for new work; understand the release train (6-month feature vs 2-year LTS).
• The JVM ecosystem (Temurin, Corretto, GraalVM) is multi-vendor — bytecode is the portability contract.
• Netflix, Amazon, and banking run Java for predictability, hiring, and decades of library investment — not hype.
• Staff engineers evaluate Java on workload fit, GC/JFR operability, and migration cost — not slogans.