Introduction

C++ developers are used to std::pair as a lightweight container for two related values. Java does not provide one exact standard-library equivalent with the same everyday role. The best answer in Java depends on what the two values mean and whether you care more about readability, mutability, or convenience.

There Is No One Perfect Built-In Pair Type

Java's standard library does not include a general-purpose Pair class that mirrors C++ directly. Instead, Java code usually chooses among these options:

• 'Map.Entry when the two values are naturally a key and a value'
• a custom class or record when the pair represents real domain data
• a third-party Pair type if the project already uses one

That design choice is very Java-like. The language tends to encourage named data rather than anonymous tuples.

Use Map.Entry for Key-Value Semantics

If the two values truly are a key and a value, Map.Entry is a reasonable standard-library substitute.

1import java.util.Map;
2
3public class Main {
4    public static void main(String[] args) {
5        Map.Entry<String, Integer> entry = Map.entry("apple", 4);
6
7        System.out.println(entry.getKey());
8        System.out.println(entry.getValue());
9    }
10}

For a mutable version, use AbstractMap.SimpleEntry:

1import java.util.AbstractMap;
2import java.util.Map;
3
4public class Main {
5    public static void main(String[] args) {
6        Map.Entry<String, Integer> entry =
7            new AbstractMap.SimpleEntry<>("apple", 4);
8
9        entry.setValue(7);
10        System.out.println(entry);
11    }
12}

This works especially well in stream transformations or temporary plumbing code.

Records Are Usually Better for Domain Data

If the pair represents something meaningful, a named type is usually better than a generic pair. In modern Java, a record is often the cleanest answer.

public record Point(int x, int y) {}

Usage is straightforward:

1public class Main {
2    public static void main(String[] args) {
3        Point p = new Point(10, 20);
4        System.out.println(p.x());
5        System.out.println(p.y());
6    }
7}

This is often clearer than a generic pair because x and y say more than left and right or first and second.

If you are on an older Java version, the same idea can be expressed with a small class:

1public final class Pair<L, R> {
2    private final L left;
3    private final R right;
4
5    public Pair(L left, R right) {
6        this.left = left;
7        this.right = right;
8    }
9
10    public L left() {
11        return left;
12    }
13
14    public R right() {
15        return right;
16    }
17}

Third-Party Pair Types Exist

Some libraries, such as Apache Commons Lang, provide a Pair type. That can be fine when:

• the dependency already exists in the project
• the pair is only a temporary helper value
• a dedicated domain type would be unnecessary noise

But a library Pair should not become the default answer for everything. If the two values have important meaning, name them.

Compare the Trade-Offs

The real question is not "How do I mimic C++ exactly?" It is "What kind of two-value object makes this Java code clearest?"

A useful rule of thumb is:

• use Map.Entry for mapping semantics
• use a record or class for business semantics
• use a library pair for short-lived infrastructure code

Here is a stream example where Map.Entry feels natural:

1import java.util.List;
2import java.util.Map;
3import java.util.stream.Collectors;
4
5public class Main {
6    public static void main(String[] args) {
7        List<String> names = List.of("ana", "ben", "clara");
8
9        Map<String, Integer> lengths = names.stream()
10            .map(name -> Map.entry(name, name.length()))
11            .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue));
12
13        System.out.println(lengths);
14    }
15}

That is a strong use case because the pair is temporary and really does mean key plus value.

Common Pitfalls

• Using Map.Entry when the data is not actually key-value data.
• Creating a generic Pair class and then using it everywhere instead of naming important concepts.
• Assuming Java cannot hold two values without importing a library.
• Ignoring mutability when choosing between Map.entry, SimpleEntry, records, and custom classes.
• Translating C++ style directly without considering what reads best in Java.

Summary

• Java has no single built-in equivalent to C++ std::pair.
• Use Map.Entry when the two values naturally mean key and value.
• Prefer a record or small class when the pair represents a real concept.
• Library Pair types are acceptable for short-lived helper values if the dependency already exists.
• In modern Java, a named record is usually clearer than a generic pair class.