Introduction

In older JDK builds, rt.jar contained the standard runtime classes, while alt-rt.jar could contain alternate implementations of selected core classes for specific JVM experiments. For HashMap, the important practical difference was not a different public API, but a different internal implementation with different performance and memory tradeoffs when the JVM chose to use the alternate runtime classes.

What rt.jar And alt-rt.jar Were

In pre-modular Java releases, rt.jar was the main runtime archive containing the standard Java platform classes. alt-rt.jar was not the normal runtime path most developers interacted with directly. It was an alternate runtime jar used for experimental or aggressive optimization modes in certain older JDK builds.

That means two things:

• your source code still targeted java.util.HashMap
• the bytecode contract stayed the same

The difference lived under the public API, inside the JDK’s internal class implementation.

Why HashMap Could Behave Differently

The alternate runtime classes were meant to optimize specific workloads. In practice, an alternate HashMap implementation could trade higher memory usage for faster access patterns. The public behavior of put, get, and iteration rules still had to match the Java specification, but implementation details such as caching strategy, bucket handling, or object layout could differ.

So if you observed a speedup, that would usually be explained by:

• different internal caching
• different object layout or probing strategy
• a runtime option enabling alternate classes optimized for some access patterns

The cost was often increased memory consumption or workload-specific regressions.

What Did Not Change

The key point is that application code should not rely on alt-rt.jar to change HashMap semantics. These aspects remained the same at the API level:

• key-value storage contract
• average constant-time lookup goal
• null handling rules defined by the JDK version
• iteration and equality semantics expected by Java collections

In other words, the difference was an implementation optimization, not a new HashMap feature.

Why This Matters Less Today

This topic mostly matters when investigating behavior in older Java runtimes. Modern Java no longer revolves around rt.jar in the same way, and historical alternate runtime jars were retired because they were difficult to support broadly and could improve some workloads while hurting others.

So if you are maintaining legacy software and see different results between environments, the presence of alternate runtime classes can explain why the same Java source behaves differently in performance tests.

Example: Benchmarking The Right Way

If you suspect runtime implementation differences, benchmark the operation you actually care about instead of assuming one jar is "better" in general.

1import java.util.HashMap;
2import java.util.Map;
3
4public class HashMapBench {
5    public static void main(String[] args) {
6        Map<Integer, Integer> map = new HashMap<>();
7
8        long start = System.nanoTime();
9        for (int i = 0; i < 1_000_000; i++) {
10            map.put(i, i);
11        }
12        for (int i = 0; i < 1_000_000; i++) {
13            map.get(i);
14        }
15        long elapsed = System.nanoTime() - start;
16
17        System.out.println("Elapsed ns: " + elapsed);
18    }
19}

The point of a benchmark like this is not to prove one implementation is universally superior. It is to show that internal runtime differences can affect workload-specific timing.

What To Do In Practice

If you are troubleshooting a legacy system:

• identify the exact JDK version
• check JVM flags that enable alternate runtime behavior
• compare memory usage as well as execution time
• avoid assuming all performance differences come from your application code

For modern Java development, the better answer is usually to upgrade and benchmark on supported runtimes rather than chase historical alternate runtime behavior.

Common Pitfalls

The most common mistake is assuming alt-rt.jar changes the Java collections API contract. It does not. Any difference is about internals and performance tradeoffs.

Another mistake is benchmarking only one micro-scenario and generalizing to every workload. Alternate implementations often helped narrow cases while hurting others.

A third issue is forgetting the memory side of the tradeoff. A faster lookup path can cost significantly more heap.

Summary

• 'rt.jar held the standard runtime classes in older Java releases.'
• 'alt-rt.jar could provide alternate implementations of selected classes such as HashMap for experimental runtime modes.'
• The public HashMap API stayed the same; the differences were internal.
• Observed speedups usually came from implementation tradeoffs, often with higher memory cost.
• For current projects, focus on supported modern JDKs rather than relying on historical alternate runtime behavior.