Trending:
Engineering Leadership

JDK basics: what CTOs need to know about Java's development foundation

The Java Development Kit remains critical infrastructure for enterprise systems, but understanding what it actually does—and when you need it versus just the runtime—matters for procurement and architecture decisions. Here's what separates the development toolkit from the execution environment.

JDK basics: what CTOs need to know about Java's development foundation

What JDK Actually Does

The Java Development Kit (JDK) is the complete software package for building Java applications. It combines three layers: the Java Virtual Machine (which executes code across platforms), the Java Runtime Environment (which provides libraries), and development tools like compilers and debuggers.

For enterprise teams, the critical distinction is this: JDK is for writing and compiling code. JRE is for running it.

The Basic Workflow

Developers write .java source files, use the javac compiler (bundled in JDK) to convert them to .class bytecode files, then execute with the java command:

javac Hello.java
java Hello

The JDK package includes javac (compiler), java (application loader), javadoc (documentation generator), jar (archiver), and jdb (debugger). Development teams need the full JDK. Production systems running existing applications only need JRE.

Enterprise Considerations

JDK deployment spans Standard Edition (general applications), Enterprise Edition (large-scale systems), and Micro Edition (embedded devices). Oracle steers JDK as a proprietary-backed derivative of the community-driven OpenJDK project.

Two architectural shifts worth noting: Alternative JVM languages like Kotlin now compile to Java bytecode without requiring traditional JDK, representing modest ecosystem diversification. Meanwhile, recent innovations enable Java bytecode to compile directly into native code without dynamic JVM execution—useful for resource-constrained environments, though this remains a specialized use case.

What This Means for Architecture Decisions

The JDK vs JRE distinction matters for licensing costs and deployment footprints. Legacy systems running stable Java applications don't need the overhead of development tools in production. Conversely, organizations building cloud-native Java applications—particularly those evaluating Java 17 to Java 21 migrations or implementing virtual threads in Spring Boot—need to understand which JDK distribution makes sense for their stack.

Java remains the second-most widely used programming language globally, with JDK serving as the standard development environment for the majority of deployments. For CTOs managing Java estates, knowing what's in the box still matters.