12 Defining Characteristics of Java With Practical Code Examples

This list goes back to the original Java marketing from the mid-1990s, where the language was pitched with a fixed set of selling points. The vocabulary is dated, and several items describe mechanisms that have since been changed, deprecated, or quietly dropped.

That matters because the list is still widely repeated as if it were a specification, and several of its claims are not true of Java today. The honest way to read it is as a historical artifact: some items describe real properties that still hold, some describe real properties that have been narrowed, and at least one, **Security**, needs substantial qualification.

THE ORIGINAL 1990s LIST, AND WHERE IT STANDS TODAY
   ┌───────────────────────────┬───────────────────────────────┐
   │ Still accurate            │ Needs qualification           │
   ├───────────────────────────┼───────────────────────────────┤
   │ Platform-independent       │ Simple                       │
   │ Architecture-neutral       │ Secure  (SecurityManager     │
   │ Robust                     │            deprecated for      │
   │ Multithreaded              │            removal in 17)     │
   │ High-Performance          │ Dynamic                      │
   │ Distributed                │ Interpreted                  │
   │ Object-Oriented (with a   │ Portable (duplicate of the   │
   │   caveat, see section 3)   │   platform claim)            │
   └───────────────────────────┴───────────────────────────────┘

This entry keeps all twelve so the vocabulary is recognisable, then states what is actually true for each one on a modern JDK.

These two are often listed separately but are the same mechanism seen from two angles, and both are solidly true. Source compiles to bytecode that contains no instructions for any particular processor, so the same .class file runs on any host with a compatible JVM.

The class file header records a format version rather than an architecture, which you can verify directly.

$ javap -v Main.class minor version: 0 major version: 61 // 61 is the Java 17 class-file format

The qualifier is that portability requires a JVM on the target. Architecture-neutral means the bytecode does not care whether the host is x86-64 or ARM64; the JVM on that host does the translating.

The list says object-oriented, and Java is genuinely class-based with real encapsulation, inheritance, and polymorphism. But the stronger form of this claim, that everything is an object, is false, and it is worth repeating here because it is the single most repeated error about the language.

int i = 5;
i.getClass();
// error: int cannot be dereferenced
i instanceof Object;
// error: unexpected type

Java has **eight primitive types** that are not objects. Autoboxing makes the distinction easy to miss, since assigning an int to an Object silently creates an Integer, but the primitives are real and they are what most numeric code actually uses.

Every type error is a compile error rather than a run-time surprise.

int n = "hello";
// error: incompatible types: String cannot be converted to int

Beyond catching mistakes, static typing is what makes automated refactoring across a large codebase safe. A tool can rename a method or change a signature and know every call site, which is the property that pays off most in a long-lived system. The cost is verbosity, since types are declared and conversions between unrelated types must be explicit.

Robustness has three separate parts, and it is worth separating them because they fail differently.

The first is **checked exceptions and enforced handling**. If a method declares throws IOException, the compiler forces you to handle it or propagate it.

// this does not compile unless IOException is handled
new java.io.FileInputStream("data.txt");

The second is **memory robustness**, meaning garbage collection plus run-time array bounds checks plus no pointer arithmetic. An out-of-bounds write throws instead of corrupting memory.

The third is **fail-fast behaviour** on type errors, since ArrayStoreException is thrown when you put the wrong type into an array.

Object[] slots = new String[1];
slots[0] = Integer.valueOf(1);
// throws ArrayStoreException

Verified: this throws ArrayStoreException, so the bad store is rejected rather than silently corrupting data.

This is the claim most often answered with "Java is interpreted, so it is slow", and that is only true of the startup phase. The JVM profiles execution and compiles frequently executed methods to optimised native code.

long start = System.nanoTime();
long sum = 0;
for (int i = 0;
i < 100_000_000;
i++) {
    sum += i;
} // gets JIT-compiled
System.out.println(sum + " in " +(System.nanoTime() - start) / 1_000_000 + " ms");

The honest caveat is that this costs something. You pay for warm-up, and a method must run enough times before it is worth compiling. So Java reaches high throughput on long-running code and pays a startup penalty, which is exactly the trade-off that hurts for short-lived command-line tools and functions that scale to zero.

Concurrency is in the language and the standard library rather than bolted on, and it has expanded considerably over the language's life.

Thread worker = new Thread(() -> System.out.println(Thread.currentThread().getName()));
worker.start();
worker.join();

The original primitives were synchronized with wait and notify, and the modern additions are the java.util.concurrent package, ReentrantLock, atomics, and CompletableFuture. Virtual threads arrived in Java 21 and change the cost model for high-concurrency services, since you can have many more threads than the thread-per-core model allowed.

The main caveat is that the concurrency model does not remove concurrency bugs. Data races and deadlocks are still your problem, and synchronized alone does not make compound operations atomic.

"Simple" is the vaguest item on the list and the one that has aged worst. It originally meant that Java avoided the sharp edges of C++, such as manual memory management and pointer arithmetic, and in that narrow sense it still holds. The same list item also covered an applet-based GUI story that is effectively over, since java.applet.Applet still exists in Java 17 but is deprecated for removal, and browsers dropped applet support long ago.

// no free(), no delete, no pointer arithmetic
StringBuilder sb = new StringBuilder();
for (int i = 0;
i < 3;
i++) {
    sb.append(i);
}System.out.println(sb);
// 012

The uncontroversially simple part is garbage collection. The contentious part is that the language grew considerably larger than the original pitch suggested.

This is the item that most needs correcting. For decades the answer was the SecurityManager, which let a program run in a restricted sandbox.

That mechanism has been withdrawn. SecurityManager is deprecated **for removal** as of Java 17, and compiling code that uses it produces a removal warning.

$ javac -Xlint:removal UseApplet.java warning:[removal] Applet in java.applet has been deprecated and marked for removal has been deprecated and marked for removal

What remains genuinely true is narrower but still useful. The **bytecode verifier** rejects malformed or type-unsafe bytecode before it runs, so forged .class files cannot corrupt the JVM stack. **Array store checking** catches type violations at run time, which is the ArrayStoreException shown earlier. **No pointer arithmetic** removes memory-corruption bugs, which is the single largest class of security bug in C and C++ code. Reflection is powerful but bounded, since setAccessible is restricted by the module system.

So: Java is memory-safe and bytecode-verified, which is real, but it is not a sandbox. A Java program can read and write any file the user can, and in-process sandboxing should not be treated as a security boundary.

"Dynamic" refers to loading classes and invoking methods at run time, which is real and heavily used by frameworks. This is not the same as being a dynamically typed language, since Java is statically typed; it means the *resolution* of what to run happens late.

Class c = Class.forName("java.lang.Integer");
Object result = c.getMethod("parseInt", String.class).invoke(null, "42");
System.out.println(result);
// 42

Verified: this resolves the class and invokes the method reflectively, and prints 42. This is exactly how dependency injection containers, ORM frameworks, and serializers work.

The trade-off is that reflection defeats compile-time checking, so a typo in a method name becomes a run-time NoSuchMethodException rather than a compile error.

Listed last because it is the most wrong. Java is a compiled language. javac compiles source to bytecode ahead of execution, and the JIT then compiles hot bytecode to native machine code at run time.

Describing Java as "interpreted" describes only the middle stage. The accurate statement is that Java is compiled twice, once ahead of time to bytecode and once at run time to native code.

This duplicates the platform-independent claim from section 2, and it is true for the same reason. One clarification is that "portable" and "native" pull in opposite directions: a native-image build is fast to start but ties you to a platform, whereas a JAR file is portable and pays JVM startup.

one .class file
          │
    ┌─────┼──────────────┬──────────────────┐
    ▼                    ▼                  ▼
  JVM/Windows         JVM/Linux         JVM/macOS
  (x86-64)            (x86-64)          (ARM64)

Pulling the above together, with the current verdict on each item.

Nine of the twelve hold up, two need qualification, and one is simply wrong.

A modern summary would add things the 1990s list never mentions, and these matter more than several items that are still on it.

Backward compatibility deserves emphasis. It is unusual in a mainstream language, and it is why a long-lived enterprise system can be upgraded in JDK steps rather than rewritten.

The short version: nine of these twelve hold, **Secure** needs heavy qualification now that SecurityManager is deprecated for removal, and **Interpreted** is simply wrong. The most valuable additions the list omits are backward compatibility, generics, lambdas, and virtual threads.