EXPLAINER

Java

Java is a statically typed, object-oriented language that runs on the JVM. Enterprises use it for long-lived services, Android's older stacks, and anywhere a stable toolchain and explicit types matter more than a short script.

Short answer: Java is a typed language on the JVM, common for large services and existing enterprise systems. It is not JavaScript. Reach for it when the organisation already runs the JVM; do not rewrite a small script into Java for fashion.

What it is

Java is a statically typed, class-based language from the 1990s that still runs a large share of business backends. You compile .java source to bytecode, and a JVM (Java Virtual Machine) runs that bytecode. The promise was portability: the same artifact on any system with a JVM. Modern Java (current long-term releases) has improved the language a lot: records, pattern matching, better collections, a module system you may never need, and a garbage collector you mostly leave alone.

Java is not JavaScript. It is not a scripting language you edit and rerun in one keystroke, though the feedback loop is much shorter than it was twenty years ago. Kotlin and Scala also run on the JVM and interoperate with Java libraries. This page stays with Java itself.

Why and when it is used

Choose Java when you are extending a system already written in it, when you need the JVM's operations story (mature profilers, well-known deployment), or when a large team wants explicit types and a culture of interfaces. Spring Boot is the usual way teams stand up an HTTP service. Android's traditional app model was Java; Kotlin is now the default for new Android UI, but Java knowledge still transfers.

Do not choose Java for a five-line file rename, a browser UI, or a one-off data plot. Python or a shell will finish first. Do not start a new small service in Java only because a job advert mentioned it, if your team ships faster in Go or C#. Do choose it deliberately when hiring, libraries (banking, enterprise SSO, older SOAP) and existing services are already JVM-shaped.

How it works

You install a JDK (compiler and libraries), not only a JRE. Source lives in packages that match folders. javac or, more realistically, Maven or Gradle compiles. The entry point is a main method. Types are declared. Null is still a problem; newer type systems and annotations help but do not remove it. Memory is garbage-collected. Threads are the classic concurrency tool; virtual threads in new JDKs make "a thread per request" less frightening.

Build tools download dependencies from Maven Central into a local cache. A fat jar or a container image is what you deploy. The app boots, opens a port, and talks to a database with JDBC or an ORM such as Hibernate. SQL still matters; the ORM does not replace knowing what query ran.

Technologies and dependencies

A current LTS JDK your platform team agrees on, Maven or Gradle, and usually Spring Boot for HTTP. JUnit runs tests. Docker is the normal way to ship a known JDK. Logging (SLF4J with a backend) is not optional in a service. Environment variables or a config server supply settings. If you call model APIs, an HTTP client and a JSON library (Jackson) are enough; you do not need a special JVM to do that.

How to get started

  1. Install an LTS JDK and java -version to confirm it is the one you think.
  2. Generate a Maven or Gradle project (Spring Initializr is fine if you want HTTP immediately; a bare project is better if you are learning the language).
  3. Write a class with main that parses a small JSON string and prints a field. Feel the ceremony and the type errors.
  4. Add one unit test. Run it from the build tool, not from a green arrow you cannot reproduce.
  5. If you start Spring, add one GET route and one configuration value from the environment.
  6. Stop before you add five starters you saw in a tutorial.

Read a stack trace from the top "Caused by". Java traces are long because frameworks wrap exceptions. The cause is the point.

Cautions and trade-offs

Ceremony is real. A simple value becomes a class, a builder and a mapper if you imitate every pattern. Records and plain types are allowed. Null and checked exceptions frustrate people coming from Kotlin or Python; handle them at boundaries rather than declaring throws Exception on every method.

Old tutorials use Java 8 syntax and obsolete libraries. Check the JDK version. Classpath hell is mostly a build-tool problem now; still, two versions of the same library will waste an afternoon. Reflection-heavy frameworks hide the control flow. When a bean is "not found", the failure is configuration, not the JVM. And do not containerise a JDK image that is a gigabyte of unused GUI libraries. Use a current runtime image and a normal build.