Java Generics, Union Types, and the “String OR Integer” Problem

The motivating problem

Consider this seemingly simple requirement:

“I want a single method that accepts either an array of Integer or an array of String, but nothing else.”

In a HackerRank-style problem, this shows up as:

Integer[] intArray = {1, 2, 3};
String[] stringArray = {"Hello", "World"};

myPrinter.printArray(intArray);
myPrinter.printArray(stringArray);

You’re explicitly not allowed to overload methods, so this is illegal:

void printArray(Integer[] a) { }
void printArray(String[] a) { } // ❌ rejected

Naturally, this leads to the question:

“Can I restrict a generic method to only String and Integer?”

Let’s explore what is possible, what is not, and why Java behaves this way.

---

The obvious (working) solutions

1. The generic solution (recommended)

class Printer {
    public <T> void printArray(T[] array) {
        for (T element : array) {
            System.out.println(element);
        }
    }
}

What this allows

• Integer[]
• String[]
• Any other reference type

Pros

• Type-safe
• Idiomatic Java
• Clean and flexible

Cons

• Does not restrict the types at all

This is the expected answer for most interview and coding-challenge scenarios.

---

2. The Object[] solution (works, but weaker)

class Printer {
    public void printArray(Object[] items) {
        for (Object item : items) {
            System.out.println(item);
        }
    }
}

Why this works

• Integer[] and String[] are both subtypes of Object[]
• Only one method → no overloading violation

Downside

• Loses compile-time type safety
• You can now pass anything:

  Object[] mixed = {1, "hello", new Date()};

This is acceptable for printing, but not ideal for real APIs.

---

The thing people want to write (but can’t)

Union type bound (not supported)

public <T extends String | Integer> void printArray(T[] array) {
    ...
}

This feels intuitive — but Java does not support union types.

---

Why this is impossible in Java

1. Java generics do not support OR constraints

Java allows intersection types (AND):

<T extends InterfaceA & InterfaceB>

But Java does not allow:

<T extends A | B>   // ❌ no union types

The type system only understands:

• “T must satisfy all of these”
• Never “T must satisfy one of these”

---

2. String and Integer are both final

You might think:

class StringOrInteger { }

and then:

<T extends StringOrInteger>

But this fails immediately because:

class MyString extends String {}   // ❌ illegal
class MyInteger extends Integer {} // ❌ illegal

Both String and Integer are final, so they cannot share a custom superclass.

The only common superclass they do share is:

Object

Which is… too broad to be useful.

---

What can be done (with trade-offs)

Option 1: Runtime checks (not type-safe)

public void printArray(Object[] items) {
    for (Object item : items) {
        if (!(item instanceof String || item instanceof Integer)) {
            throw new IllegalArgumentException("Only String or Integer allowed");
        }
        System.out.println(item);
    }
}

Pros

• Enforces the rule

Cons

• Errors occur at runtime, not compile time
• Easy to misuse

---

Option 2: Wrapper + marker interface (type-safe, but heavy)

interface IntOrString { }

class MyString implements IntOrString {
    String value;
    MyString(String value) { this.value = value; }
    public String toString() { return value; }
}

class MyInteger implements IntOrString {
    Integer value;
    MyInteger(Integer value) { this.value = value; }
    public String toString() { return value.toString(); }
}

public <T extends IntOrString> void printArray(T[] array) {
    for (T t : array) {
        System.out.println(t);
    }
}

Pros

• Compile-time restriction
• Clean type system

Cons

• Requires wrapping values
• Overkill for simple tasks

---

Why Java is like this (design philosophy)

Java’s generics were designed to:

• Be backward compatible
• Avoid runtime overhead
• Keep the type system simple and predictable

Union types introduce:

• Complex overload resolution
• Ambiguous method selection
• Harder type inference

Java chose simplicity and safety over expressiveness here.

---

How other languages handle this

Kotlin (yes, but indirectly)

fun printArray(arr: Array<out Any>) {
    arr.forEach { println(it) }
}

Kotlin still lacks true union types, but:

• Has better variance (out, in)
• Stronger type inference

---

Scala (much more powerful)

def printArray(arr: Array[String | Int]): Unit =
  arr.foreach(println)

Scala supports union types directly.

---

TypeScript (designed for unions)

function printArray(arr: (string | number)[]) {
    arr.forEach(console.log);
}

This is exactly what you wanted Java to do.

---

Swift

func printArray(_ arr: [Any]) {
    for item in arr {
        print(item)
    }
}

Swift allows this but relies on runtime checks unless you use enums.

---

The final takeaway

In Java:

• ❌ You cannot restrict generics to “String OR Integer”
• ❌ You cannot create a union superclass
• ❌ You cannot express OR constraints in type bounds
• ✅ You can use unrestricted generics
• ✅ You can enforce rules at runtime
• ✅ You can redesign with wrappers if needed

That’s why the best Java answer to this problem remains:

public <T> void printArray(T[] array)

So remember, if you were thinking about union types, congrats.
You’re already thinking beyond Java’s surface level and into type system design, which is exactly where strong developers end up.